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1.0  SUMMARY 


On  the  DARPA  Initiative  in  Concurrent  Engineering  (DICE)  Phase  4  contract,  Westinghouse 
conducted  an  Electronics  Pilot  Project  using  the  DICE  technology  developed  on  Biases  3  and  4  of 
the  program.  The  primary  objective  was  to  assess  the  capability  of  this  technology  to  enable 
computer-based  concurrent  engineering  by  applying  it  to  the  electronics  design  process.  Also  as 
part  of  the  effort,  a  large  number  of  recommendations  were  developed  to  improve  this  emerging 
technology  and  enhance  its  benefits  to  the  product  development  process.  The  primary  conclusion 
drawn  from  the  project  was  that  the  DICE  technology  has  a  large  potential  to  improve  the  proauct 
development  process  in  terms  of  decreased  product  development  cost,  reduced  cycle  time,  and 
improved  product  quality  by  enhancing  the  involvement  of  all  disciplines  early  in  the  design 
process.  The  specific  implementation  s  of  the  four  DICE  tools  evaluated  in  this  pilot  project, 
however,  provided  only  a  small  portion  of  this  potential.  The  numerous  recommendations 
developed  during  the  course  of  the  project  will,  if  incorporated  into  the  DICE  technology,  help  the 
technology  reach  its  full  potential. 

To  perform  this  project,  Westinghouse  applied  four  of  the  DICE  concurrent  engineering  enabling 
tools  (Meeting  on  the  Net,  Project  Coordination  Board,  Electronic  Design  Notebook,  and 
Communications  Manager)  within  its  electronics  design  process.  To  assess  the  impact  of  this 
technology,  Westinghouse  designed  a  high  performance  programmable  signal  processor  module  as 
the  pilot  project  demonstration  vehicle.  A  multi-disciplined  team  consisting  of  designers  from  the 
systems  engineering,  electrical  engineering,  mechanical  engineering,  producibility,  and 
supportability  disciplines,  as  well  as  a  program  lead,  performed  the  design  activity  using  this  DICE 
technology.  The  design  tasks  consisted  of  those  representative  of  the  front  half  of  the  Full  Scale 
Development  (FSD)  process  used  for  developing  military  electronics  systems  and  ranged  from  the 
initial  requirements  capture  and  analysis  tasks,  through  preliminary  design  tasks  which  included  a 
Preliminary  Design  Review  (PDR),  and  into  the  detailed  design  phase.  Quantitative  metrics  were 
taken  during  this  activity  and  showed  a  IS  to  20%  improvement  in  the  design  process  metrics.  The 
design  team  felt,  however,  that  a  much  larger  potential  for  improvement  (over  50%)  existed,  and 
developed  technology  improvement  strategies  and  provided  specific  recommendations  for 
obtaining  this  improvement 

Hie  recommendations  to  improve  the  DICE  technology  fell  into  two  major  categories:  the  usability 
of  the  software  in  performing  its  intended  functions,  and  the  design  and  implementation  of  the 
DICE  software  itself.  Usability  can  be  described  as  the  ability  of  the  DICE  software  to  perform  the 
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correct  functions  needed  by  the  end  user  product  developers  in  an  efficient  manner.  A  summary  of 
these  recommendations  in  areas  most  needing  improvement  is  as  follows: 

•  Tool  functions:  Many  of  the  tool  functions  appeared  to  be  derived  from  a  software 
developer's  perspective  of  what  product  designers  need  to  more  efficiently  perform  their  job, 
as  opposed  to  being  derived  from  an  organized  set  of  detailed  requirements  obtained  from  the 
end  users  themselves.  As  a  result,  many  of  the  real  time  and  cost  saving  functions  desired  by 
the  end  users  were  not  addressed,  and  some  of  the  functions  which  were  implemented  in  the 
software  were  not  perceived  by  the  end  users  as  being  particularly  important  in  assisting  in 
their  job  functions.  Westinghouse  recommends  that  a  structured  process  be  used  to  redefine 
the  required  mol  functions  and  document  the  rationale  for  their  selection. 

•  User  interface:  There  was  a  wide  variety  of  types  and  quality  of  user  interfaces  used  on  this 
mix  of  DICE  software.  In  general,  many  of  the  interfaces  had  deficiencies  which  quickly 
degraded  the  impact  of  the  tools.  Westinghouse  recommends  that  basic  principles  of  human- 
computer  interface  technology  be  applied  to  this  software  to  simplify  and  provide  consistency 
in  the  interface  presented  to  the  aid  user. 

•  Integration:  A  major  element  of  computer-assisted  concurrent  engineering  is  electronically 
sharing  data,  and  a  major  element  of  electronically  sharing  data  is  the  integration  of  the  DICE 
tools  with  themselves,  as  well  as  with  the  rest  of  the  design  environment  Most  of  the 
technology  evaluated  had  limitations  in  sharing  and  exchanging  data.  Higher  levels  of 
integration  between  tools  are  required  in  subsequent  enhancements  to  these  tools. 

The  other  major  recommendation  from  this  evaluation  is  that  a  more  structured  approach  be  applied 
to  the  development  process  for  the  DICE  software  itself.  Experiences  on  this  phase  indicated  that 
many  of  the  recommendations  for  improvement  could  not  be  easily  incorporated  due  to  software 
implementation  decisions  previously  made  which  restricted  enhancement  of  the  software.  A  top 
down  development  approach  which  considers  all  design  issues  from  the  start,  including  security, 
incremental  functional  enhancements,  and  integration  with  other  software,  will  simplify  the 
development,  modification,  and  deployment  of  this  technology. 

In  summary,  the  DICE  technology  evaluated  on  this  pilot  project  has  shown  potential  for 
improving  the  electronics  development  process.  However,  additional  effort  is  required  to  reach  the 
full  benefit  of  computer  assisted  concurrent  engineering.  A  concurrent  engineering  approach 
applied  to  the  DICE  technology  development  process  itself,  involving  a  team  of  end  users  and 
system  support  personnel,  working  closely  with  the  DICE  software  developers,  will  speed  the 
attainment  of  these  benefits. 
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2.0  INTRODUCTION 


The  mission  of  the  DICE  program  is  to  develop  computer-based  concurrent  engineering 
technology,  to  validate  this  technology  in  industrial  design  environments  called  Pilot  Projects,  and 
to  establish  a  national  resource  for  concurrent  engineering  expertise  in  the  form  of  the  Concurrent 
Engineering  Research  Center  (CERC)  at  West  Virginia  University  in  Morgantown,  West  Virginia. 
To  accomplish  these  goals,  the  DICE  program  has  involved  collaboration  between  the  Department 
of  Defense,  industry,  and  academia.  Development  of  the  basic  technology  is  being  performed  by  a 
combination  of  industry  and  university  participants,  and  validation  by  application  has  been 
primarily  an  industry  role.  Initial  DICE  technology  was  directed  at  mechanical  product  design 
activities,  and  was  later  expanded  to  the  electronics  product  domain. 

Concurrent  engineering  practices  in  the  past  have  centered  on  the  creation  of  "tiger  teams",  which 
have  consisted  of  multidisciplined  teams  of  product  developers  who  were  physically  collocated. 
Information  on  the  product  design  and  the  various  development  issues  was  shared  as  a  natural 
result  of  the  team  effect  arising  from  the  physical  collocation.  As  project  size  and  complexity 
increases  and  as  parts  of  corporations  become  scattered  geographically  due  to  practices  such  as 
distributed  manufacturing,  this  physical  collocation  becomes  increasing  difficult.  Also,  as  the 
design  process  becomes  increasingly  reliant  on  computer-based  design  tools,  data  is  more 
efficiently  used  if  it  can  be  shared  electronically  rather  than  verbally  or  through  written 
communications.  The  DICE  concept  is  based  on  computer  technology  which  provides  a  "virtual 
tiger  team",  wherein  the  product  developers  are  linked  within  a  network  and  can  be  remotely 
located,  and  data  can  be  shared  electronically  among  the  various  design  tools. 

The  thrust  of  the  earlier  phases  of  DICE  has  been  focused  on  developing  the  technology  to  enable 
this  computer  based  concurrent  engineering.  The  DICE  technology  development  has  targeted  five 
areas  of  process  enhancement:  (1)  sharing  information  to  allow  the  product  development  team  to 
have  common  visibility  of  the  product  as  it  is  evolving,  (2)  team  coordination  to  ensure  that  the 
team  members  are  working  toward  a  common  goal,  (3)  networked  collocation  to  enable  remotely 
located  personnel  to  participate  fully  in  the  design,  (4)  integrated  tools  and  frameworks  to  allow 
electronic  data  to  be  shared  between  systems,  and  (5)  capturing  corporate  history  to  allow 
continuity  and  lessons  learned  to  be  applied  from  past  projects  to  new  projects.  A  number  of 
individual  DICE  software  tools  have  been  developed  to  meet  these  needs. 
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Westinghouse  has  been  a  participant  on  DICE  in  Phases  3  and  4  as  the  Electronics  Pilot  Project 
The  role  of  Westinghouse  has  been  to  apply  the  emerging  DICE  technology  to  the  military 
electronics  development  environment  to  measure  its  benefits  in  enabling  computer  based  concurrent 
engineering,  to  provide  constructive  feedback  to  the  DICE  technology  developers  to  enable 
continuous  improvement  of  this  technology,  and  to  transfer  electronics  design  process  information 
to  CERC  to  increase  their  knowledge  base  for  future  self-sufficiency.  To  accomplish  this  task, 
Westinghouse  has  worked  closely  with  the  software  developers  at  both  the  Concurrent  Engineering 
Research  Center  and  GE  Corporate  Research  and  Development  (GE/CRD)  on  a  number  of  DICE 
tools  and  how  these  tools  impact  the  development  process.  In  Phase  3,  Westinghouse  performed 
extensive  process  modeling  of  the  As-Is  electronics  development  process,  and  provided  this 
information  to  CERC  as  a  baseline  to  be  used  for  their  electronics  scenario  at  their  test  bed. 
Westinghouse  then  identified  a  number  of  process  improvement  areas  to  be  used  for  creation  of  a 
To-Be  process  incorporating  DICE  technology  for  enhanced  levels  of  concurrent  engineering. 
Westinghouse  also  implemented  a  DICE  laboratory,  networked  with  the  extensive  Westinghouse 
development  environment,  as  a  host  site  for  the  DICE  software.  Evaluation  of  the  software 
available  in  Phase  3  (which  was  primarily  demonstration  level  software)  was  performed,  and 
detailed  feedback  to  the  developers  was  provided. 

On  Phase  4,  this  activity  was  continued  to  a  greater  level  of  depth.  The  To-Be  process  was  defined 
in  finer  detail  using  the  Westinghouse  Integrated  Product  Development  Team  Guide,  which  is  the 
master  template  used  by  Westinghouse  for  implementing  concurrent  engineering.  The  updated 
DICE  software  was  further  evaluated  and  mapped  into  the  appropriate  portions  of  this  development 
process.  A  pilot  project  design  vehicle  was  chosen  and  a  multidisciplined  concurrent  engineering 
team  was  formed.  This  team  performed  the  design  of  a  signal  processor  module  for  a  radar  system 
using  the  DICE  technology,  and  metrics  were  taken  on  the  design  process. 

The  detailed  procedure  used  on  the  pilot  project  and  the  results  are  described  in  Section  3.  Section 
4  summarizes  the  conclusions  drawn  from  the  pilot  project  experiences,  and  Section  5  provides 
recommendations  on  future  DICE  activities. 

Additional  backup  information  is  found  in  the  references  listed  in  Section  6.  Appendices  A  and  B 
contain  detailed  information  on  the  electronics  module  product  and  process  models,  respectively, 
which  were  developed  for  use  on  the  project  Additional  metrics  data  is  found  in  Appendix  C. 


Page  4 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report 


3.0  PROCEDURE  AND  RESULTS 


The  procedure  used  by  Westinghouse  in  its  pilot  project  application  of  DICE  technology  consisted 
of  multiple  levels  of  use  and  evaluation  of  the  DICE  software,  with  increasing  amounts  of  in¬ 
context  application.  An  overview  of  these  various  tasks  in  Phase  4  are  shown  in  Figure  1.  The 
three  major  efforts  consisted  of  (1)  unit  level  evaluation  of  the  individual  DICE  prototype  software 
elements,  (2)  development,  maintenance  and  support  of  a  DICE-based  computing  environment  at 
Westinghouse,  and  (3)  use  of  the  DICE  technology  in  a  pilot  project  design  activity. 


DICE  Technology  Developers  (Iterative  Development/Evaluation/Enhancement) 

•  Software  Development 

•  Installation  &  Training  Support 

•  Integration  Support 


Support 

Unit  Evaluation  of  DICE  Prototype  Software 

•  Project  Coordination  Board 

•  Heating  on  the  Not 

•  Electronic  Design  Notebook 

•  Communications  Manager 


Pitot  Project 
Recommendattona 


DICE  Application  to  Pilot  Project  Design 

•  Design  Vehicle 

•  Product  Model 

•  Design  Team 

•  Pro  case  Model 


Figure  1.  Overview  of  DICE  Phase  4  Tasks. 

The  unit  level  evaluation  accomplished  many  functions.  Since  these  tools  were  highly 
developmental,  this  evaluation  provided  an  initial  familiarization  and  evaluation  of  the  capabilities 
of  the  technology.  In  this  activity,  DICE  tools  were  installed  and  supported  in  the  Westinghouse 
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DICE  environment,  the  pilot  project  design  team  users  were  trained  in  the  operation  of  the  tools, 
and  the  tools  were  exercised  by  users.  During  the  course  of  these  activities,  the  users  and  system 
maintainers  were  continually  evaluating  and  providing  feedback  on  the  tools  in  the  areas  of 
software  malfunctions  ("bugs”),  functional  improvements,  and  support  issues.  The  end  objective 
of  this  task  was  to  determine  a  particular  mol's  readiness  for  application  to  the  pilot  project,  or  the 
improvements  required  to  bring  it  to  a  level  of  maturity  for  pilot  project  application.  The  individual 
tool  evaluations  are  discussed  in  Section  3.1  and  its  subsections. 

In  support  of  the  unit  level  evaluation,  a  DICE  laboratory  environment  was  set  up  and  maintained. 
This  environment  was  located  in  the  midst  of  the  digital  electronics  design  area  at  Westinghouse, 
and  was  connected  to  the  extensive  Westinghouse  design  environment  via  ethemet.  Integration 
tasks  were  performed  to  provide  proper  functioning  and  communication  of  the  wide  variety  of  tool 
functions.  The  DICE  lab  was  staffed  with  systems  support  personnel  whose  functions  were  to 
maintain  the  environment,  and  also  provide  a  critical  evaluation  of  the  issues  involved  with  the 
eventual  widespread  implementation  of  such  an  environment  The  environment  and  its  integration 
issues  are  discussed  in  Section  3.2  and  its  subsections. 

The  culmination  of  the  previous  tasks  was  the  application  of  the  DICE  technology  to  a  "real  world" 
design  activity.  The  electronics  pilot  project  followed  a  path  developed  on  DICE  for  the  insertion 
of  concurrent  engineering  technology  into  the  development  process.  This  procedure  consisted  of 
the  following  steps: 

•  Selection  of  a  pilot  project  vehicle,  forming  a  multi -disciplined  product  development  team, 
and  selecting  an  appropriate  segment  of  the  product  development  process. 

•  Documentation  of  the  current  development  process,  which  included  the  various  phases  of  the 
process,  all  of  the  disciplines  involved  for  each  phase  and  their  respective  tasks,  the 
information  needed  by  each  discipline,  and  the  outputs  of  each  discipline. 

•  Identification  of  current  process  "pain  points",  where  the  process  has  shortcomings,  and 
development  of  improvements  in  the  product  development  process. 

•  Mapping  of  die  DICE  technology  being  developed  into  the  identified  process  improvement 
areas  and  determining  potential  benefits. 

•  Selection  of  metrics  to  be  taken  to  measure  the  effectiveness  of  the  process  improvements, 
including  baseline  values. 

•  Performance  of  the  product  design  per  the  improved  process  using  the  DICE  technology  and 
taking  metrics  on  the  steps  in  the  process. 


Page  6 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report 


•  Analysis  of  the  metrics  and  providing  recommendations  for  further  improvement  of  both  the 
technology  and  its  application  to  the  process. 

The  pilot  project  design  activity  is  discussed  in  Section  3.3  and  its  subsections. 


3.1  INDIVIDUAL  DICE  TOOL  EVALUATIONS 

The  individual  DICE  tool  evaluations  were  a  critical  part  of  the  overall  pilot  project  Since  this  was 
the  first  time  that  designers  from  the  end  user  community  had  exercised  these  tods  in  an  industrial 
environment,  a  large  number  of  key  improvements  and  unmet  user  requirements  were  identified 
and  corrective  actions  taken.  Although  much  more  still  remains  to  be  done  on  tool  improvement  at 
the  end  of  Phase  4,  performing  die  pilot  project  design  without  this  step  would  have  resulted  in  an 
unusable  environment  The  DICE  tools  which  were  evaluated  in  this  task  were  the  Project 
Coordination  Board  (PCB),  Meeting  On  The  Net  (MONET),  Electronic  Design  Notebook  (EDN), 
and  the  Communications  Manager  (CM).  These  evaluations  provided  a  detailed  critique  of  the  tool 
from  the  end  users'  and  system  administrators'  perspectives.  The  unit  evaluation  covered  five 
areas:  installation,  training,  functions,  system  support,  and  documentation.  The  results  of  these 
evaluations  were  documented  in  detail  for  each  tool  individually  and  submitted  separately  to 
DARPA  during  the  course  of  Phase  4.  The  unit  evaluation  procedure  is  shown  in  Figure  2.  The 
following  paragraphs  provide  a  summary  of  each  tool  evaluation. 


Figure  2.  Individual  Tool  Evaluation  Procedure. 
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3.1.1  Project  Coordination  Board  (PCB) 

The  PCB  was  created  to  provide  a  number  of  capabilities  for  electronic  team  coordination.  It  was 
to  contain  features  such  as  project  task  management  and  visibility,  product  attribute  visibility, 
constraint  management,  design  assessment,  and  Quality  Function  Deployment  assistance.  During 
the  course  of  the  PCB  evaluation,  Westinghouse  installed  and  evaluated  five  prototype  versions  of 
the  PCB  software.  The  versions  evaluated  had  only  partial  functionality,  as  some  features  were 
still  in  development  The  capabilities  evaluated  consisted  of  the  process,  or  task,  management 
feature,  and  the  product  model  feature.  The  constraint  management  design  assessment  and  QFD 
capabilities  were  not  in  any  of  the  versions  evaluated.  The  details  of  the  PCB  evaluation  are 
coveted  in  a  separate  report  entitled  “Project  Coordination  Board  Evaluation  Report”  [1],  submitted 
by  Westinghouse  on  this  contract  The  following  paragraphs  summarize  die  primary  aspects  of  die 
evaluation. 

During  the  initial  stages  of  the  PCB  evaluation,  the  pilot  project  design  team  identified  a  number  of 
potential  payback  areas  in  which  the  PCB  could  improve  the  product  development  process. 
Having  the  product  model  available  on-line  to  the  team  would  provide  a  large  improvement  in 
design  visibility.  The  capability  to  find  all  desired  aspects  of  the  design  efficiendy  by  browsing  a 
standardized  product  model  would  provide  a  cost  and  time  savings,  but  more  importantly,  would 
reduce  rework  and  redesign  due  to  instantaneous  flowdown  of  changes  in  die  product  model.  The 
visibility  provided  by  the  on-line  process  model  would  provide  the  development  team  members 
with  clear,  up-to-date  understanding  of  tasks,  outputs,  schedule  constraints,  and  relationships 
between  tasks,  as  well  as  providing  the  project  leader  with  capability  for  "electronic  page  and  line" 
schedule  status.  The  benefit  should  be  improved  schedule  performance  by  the  project  team. 
Technical  performance  monitoring,  as  recommended  in  Military  Standard  491  on  systems 
engineering,  would  be  assisted  by  the  constraint  management  and  design  assessment  capabilities. 

The  PCB  was  initially  evaluated  against  the  claimed  capability  which  was  described  in  its  user 
manual  and  presented  during  the  training  sessions.  In  these  evaluations,  the  users  exercised  every 
function  of  the  software.  Problems  were  discovered,  documented,  and  recommendations  were 
developed.  The  PCB  was  next  evaluated  with  product  model  and  process  model  data  developed 
for  use  in  the  electronics  pilot  project  A  product  model,  which  is  the  template  for  all  required 
information  about  the  product  was  created  and  entered  into  the  PCB,  and  the  users  accessed  this 
data  and  provided  recommendations  on  improvements.  A  process  model,  or  task  schedule,  was 
created,  translated  into  PCB  compatible  format  and  loaded.  The  users  then  exercised  this  aspect 
of  the  PCB  and  again  provided  recommendations.  Up  to  four  users  were  accessing  the  PCB 
simultaneously  during  this  series  of  evaluations. 
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The  primary  conclusion  from  these  evaluations  is  that  the  versions  of  the  PCB  which  were 
evaluated  on  Phase  4  need  further  improvement  before  they  can  be  considered  usable  and  can 
provide  a  productivity  enhancement  in  an  actual  design  environment.  The  major  problems 
consisted  of  low  reliability,  low  user  interface  efficiency,  and  the  requirement  for  additional 
functionality,  such  as  the  Design  Assessment  Tool  (DAT),  Constraint  Management  (CM)  and 
project  management  functions.  The  other  major  limitation  was  the  lack  of  connectivity  of  the  PCB 
to  other  tools  and  data  bases.  A  summary  of  high  level  recommendations  for  improvements  in 
these  areas  is  provided  below. 

•  Reliability:  The  reliability  of  the  software  needs  to  be  improved  by  several  orders  of 
magnitude.  System  Support  personnel  were  required  to  almost  constantly  assist  the  users  in 
recovering  from  PCB  failures  and  connection  failures. 

•  User  Interface:  The  user  interface  was  very  non-intuitive  and  inflexible,  making  it  very 
difficult  for  users  to  find  both  product  and  process  data,  as  well  as  to  update  these  data.  The 
product  and  process  data  used  for  evaluation  consisted  of  a  few  hundred  elements,  which  is 
small  compared  to  a  typical  large  project  However,  this  small  amount  of  data  overwhelmed 
the  PCB  screen,  requiring  excessive  scrolling  and  searching  by  the  users  to  find  data.  Task 
model  information  was  jumbled  and  confusing,  as  shown  in  Figure  3.  The  excessive 
layering  of  menus  and  obscure  terminology  also  prevented  users  from  efficiently 
manipulating  this  data.  Standard  principles  of  human -computer  interface  knowledge  should 
be  applied  to  make  this  interface  as  user  friendly  and  efficient  as  typical  commercial  software 
in  order  to  gain  user  acceptance  and  productivity  enhancement  from  this  tool. 

•  Functionality:  The  actual  functions  performed  by  the  PCB  versions  which  were  evaluated 
only  provide  minimal  assistance  to  concurrent  engineering  in  their  current  implementation. 
The  DAT  and  CM  functions,  which  were  not  available  for  evaluation,  can  add  value  to  the 
product  development  process,  but  the  same  implementation  issues  discussed  above  must  be 
applied  to  these  features,  or  the  potential  benefit  will  be  lost.  The  current  version  of  the  PCB 
also  falls  far  short  of  providing  the  user  with  any  meaningful  project  management  facility  due 
to  the  lack  of  certain  key  functions.  These  include  time  and  cost  management  functions  that 
are  the  very  essence  of  any  project  management  activity.  The  lack  of  these  functions, 
coupled  with  the  lack  of  user  friendliness  described  above,  virtually  rendered  the  PCB 
useless  as  a  project  management  tool 

•  Connectivity  to  Data:  The  PCB  versions  which  were  evaluated  essentially  functioned  as 
stand-alone  software.  Initially  loading  the  required  project  data  was  cumbersome  and 
required  manual  steps.  There  was  no  linking  to  constraint  or  requirements  data  bases  for 
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initial  data  input  and  updating,  and  there  was  no  linking  to  design  tools  to  provide  a  means  of 
putting  current  design  data  into  the  PCB  knowledge  base.  Requiring  users  to  do  this 
manually  is  not  a  good  design  practice,  as  it  will  be  error  prone  and  will  not  improve 
productivity. 


Figure  3.  PCB  User  Interface  for  Task  Structure. 


The  PCB  concept  has  the  highest  potential  to  enable  computer  based  concurrent  engineering  by 
providing  designers  with  organized  access  to  data.  However,  the  current  implementation  needs 
improvement,  and  the  recommendations  outlined  above  are  required  to  improve  the  quality  of  this 
tool  to  provide  improved  concurrent  engineering  productivity. 

3.1*2  Meeting  On  The  Net  (MONET) 

The  MONET  software  was  developed  on  DICE  to  provide  multimedia  electronic  conferencing 
capabilities  to  remotely  located  personnel  connected  over  a  network.  During  the  course  of  Phase  4, 
Westinghouse  installed  and  evaluated  three  prototype  versions  of  the  MONET  software.  The 
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functions  available  with  the  versions  evaluated  consisted  of  "keyboard"  meetings  with  image  cut 
and  paste,  and  the  shared  application  function  which  operated  with  single  window-type  application 
programs.  MONET  functions  which  were  in  process  at  CERC  but  not  available  for  evaluation  at 
the  Westinghouse  pilot  site  were  the  shared  application  function  operable  with  multiwindow-type 
application  programs,  and  the  remote  presentation  function.  The  audio  and  video  features  could 
not  be  evaluated  primarily  due  to  hardware  limitations  at  the  Westinghouse  site.  A  complete 
description  of  the  MONET  evaluation  and  recommendations  is  found  in  the  report,  'Meeting  chi  the 
Net  Evaluation  Report"  [2],  submitted  separately  by  Westinghouse  on  this  contract  A  summary  of 
the  MONET  evaluation  is  given  below. 

During  the  initial  stages  of  MONET  evaluation,  the  pilot  project  design  team  identified  a  number  of 
potential  payback  areas  in  which  MONET  could  improve  the  development  process.  A  large 
potential  was  seen  in  having  spontaneous  mini-design  reviews  using  the  shared  application 
capability,  allowing  more  design  review  and  feedback  early  in  the  development  effort  This  would 
prevent  the  typical  problem  of  having  large  numbers  of  action  items  requiring  redesign  during  the 
more  formal  Preliminary  and  Critical  Design  Reviews  (PDR  and  CDR)  normally  held  during  the 
development  process.  Areas  identified  for  these  reviews  included  use  with  the  electronics  CAD 
system  to  interactively  review  block  diagrams,  schematics,  and  other  electronics  design  data  in 
process,  use  with  EDN  to  allow  interactive,  multidiscipline  document  generation  and  editing,  and 
use  with  the  GE  Concurrent  Engineering  Workstation  (CEW)  for  review  of  tradeoff  and  analysis 
data.  Another  potential  was  seen  in  simply  having  enhanced  communication  between  die  design 
team  for  remotely  located  team  members.  The  potential  benefits  from  MONET  were  seen  as 
providing  time  and  cost  savings,  error  and  redesign  reduction,  and  a  travel  savings. 

The  procedure  for  the  evaluation  was  to  use  a  multi-disciplined  team,  establish  conference 
scenarios  based  upon  the  tool  functionality,  and  conduct  the  meetings.  The  majority  of  the 
MONET  evaluation  activity  consisted  of  functional  evaluation  and  feedback  to  CERC  on 
improvements  to  make  MONET  a  valuable  tool  to  support  the  concurrent  engineering  activities  of 
preliminary  and  detailed  design.  The  individuals  from  the  various  disciplines  participated  in 
several  conferences  to  evaluate  the  capabilities  of  MONET.  Due  to  lack  of  audio  capability  and  the 
slowness  of  keyboard  communication,  Westinghouse  had  to  implement  a  strict  synchronization 
procedure  in  the  user  evaluations  in  order  to  coordinate  who  was  commenting  and  who  was 
responding.  One  major  conclusion  of  the  evaluation  was  that  the  conference  function  without 
voice  is  virtually  unusable  for  all  but  the  simplest  communications.  The  addition  of  voice  will 
provide  the  biggest  increase  of  usability.  The  next  largest  improvement  involves  the  capability  to 
run  multiwindow-type  applications  in  the  shared  application  mode.  The  addition  of  video  may 
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provide  some  benefit,  but  actual  pilot  project  usage  is  required  to  determine  if  the  benefits  outweigh 
the  additional  costs.  The  reliability  of  MONET  also  needs  improvement,  as  many  inconsistencies 
in  MONET  operation  were  experienced  from  session  to  session.  This  required  a  significant  system 
support  activity,  and  a  more  robust,  maintenance-free  capability  is  required.  Finally, 
Westinghouse  recommends  that  the  whole  approach  to  the  user  interface  be  revisited  to  simplify 
and  integrate  the  functions  to  allow  a  more  "natural"  meeting  to  take  place.  An  approach  using  a 
single  menu  window,  instead  of  the  heavily  layered  menu  approach  currently  implemented  (shown 
in  Figure  4),  would  provide  a  more  productive  tool  by  reducing  user  confusion.  This  became 
apparent,  as  the  screen  became  very  cluttered  with  many  windows,  especially  during  a  shared 
application. 
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Figure  4.  MONET  User  Interface. 
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In  summary,  the  versions  of  MONET  evaluated  during  Phase  4  had  limited  application  to  the  pilot 
project,  primarily  due  to  the  lack  of  shared  application  capability  to  operate  multiwindow 
programs,  which  form  the  bulk  of  the  software  used  by  the  electronics  industry  in  modem  day 
design  activities.  The  improvements  of  a  more  efficient  user  interface,  automatic  search  and  call, 
and  improved  indexing/storage/retrieval  will  also  greatly  improve  its  usability.  Westinghouse  feels 
the  MONET  concept  has  good  potential  for  improving  the  concurrent  engineering  process  in  a 
geographically  distributed  environment,  but  proper  attention  must  be  given  to  the  details  of 
implementation,  which  will  determine  die  ultimate  usability  and  benefit  of  the  tool. 

3.1.3  Electronic  Design  Notebook  (EDN) 

The  EDN  provides  an  electronic  means  of  capturing  the  documentation  and  rationale  of  the  design 
activity  to  provide  a  corporate  history  which  can  be  applied  to  future  designs.  During  the  course  of 
Phase  4,  two  implementations  of  EDN  based  on  different  underlying  software  packages  were 
evaluated.  Ten  iterative  versions  of  the  EDN  based  on  the  Framemaker  commercial  desktop 
publishing  software  were  installed  and  evaluated  early  in  the  phase,  and  one  version  of  the  EDN 
based  on  the  Aster*X  office  integration  software  was  received  and  evaluated  late  in  the  phase.  The 
details  of  the  Framemaker-EDN  evaluation  are  covered  in  a  separate  report  entitled  "Electronic 
Design  Notebook  (EDN)  Evaluation  Report"  [3],  which  was  submitted  separately  under  this 
contract.  The  following  section  summarizes  the  evaluation  of  that  EDN.  The  Aster*X-EDN 
version  was  evaluated  and  used  during  the  last  quarter  of  the  pilot  project,  and  Section  3. 1.3. 2, 
gives  a  summary  of  that  EDN*s  evaluation  and  recommendations. 

3. 1.3.1  Framemaker-EDN 

The  Framemaker  based  EDN  evaluation  effort  was  done  as  a  dynamic  process  reflecting  the 
continuing  changes  being  made  to  the  tool.  An  initial  evaluation  involved  several  iterations  to 
improve  performance  and  capabilities  to  bring  the  EDN  software  from  development-quality 
software  to  a  functioning  tool  that  could  support  a  design  environment.  The  final  phase  of 
evaluation  used  the  EDN  for  the  generation  of  the  EDN  evaluation  report  mentioned  previously. 

As  part  of  the  initial  stages  of  EDN  evaluation,  the  pilot  project  design  team  identified  a  number  of 
potential  payback  areas  in  which  the  EDN  could  improve  die  development  process.  One  major  area 
was  the  on-line  generation  of  engineering  documents.  Many  of  the  documents  developed  in  the 
course  of  a  project,  such  as  specifications,  tradeoff  reports,  and  interface  documents,  require 
inputs  from  multiple  disciplines.  The  capability  for  efficiently  networked  "group  authoring"  of 
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these  documents  would  provide  a  time  and  cost  payback  due  to  rapid  document  creation,  review, 
and  updates. 

Another  use  foreseen  for  EDN  was  as  the  primary  on-line  information  source  for  current  projects. 
A  design  team  needs  electronic  access  to  current  and  previous  versions  of  items  such  as 
requirements  documents,  design  memos,  and  sizing  tradeoffs.  Error  reductions  and  time  savings 
due  to  having  accurate  information  available  on-line  was  seen  as  the  payback. 

A  final  major  use  for  the  EDN  was  in  capturing  the  design  intent  for  use  on  future  projects  to  create 
a  "corporate  memory".  Information  such  as  the  rationale  for  design  decisions  and  detailed 
descriptions  of  design  functions  would  allow  easier  reuse  or  modification  of  designs  for  future 
designs,  resulting  in  time  savings  and  error  reductions. 

During  the  initial  evaluation  of  this  tool,  a  high  level  of  system  support  was  required  for  setting  up 
the  necessary  directories  and  access  levels  so  all  team  members  could  perform  the  EDN  evaluation. 
This  process  was  then  compared  to  Westinghouse  requirements  for  installation,  directory 
management,  system  configuration,  and  security.  The  users  evaluated  the  EDN  by  creating 
various  documents,  meeting  notes,  and  memos,  and  then  documenting  the  problems  that  occurred, 
reliability,  performance,  user  response  to  the  available  functions,  interface,  and  the  amount  of 
training  required.  For  the  final  phase  of  the  evaluation,  all  team  members  generated  the  sections  of 
the  EDN  report,  sharing  the  information  and  files  as  needed.  The  sections  were  pulled  together, 
formatted,  and  published  within  the  EDN  tool. 

The  functional  evaluation  of  the  EDN  provided  a  large  quantity  of  recommendations  for 
improvement.  The  primary  conclusion  drawn  from  the  Framemaker  EDN  evaluation  is  that  the 
concept  of  an  Electronic  Design  Notebook  to  enable  concurrent  engineering  has  great  merit  The 
implementation  of  an  EDN,  however,  must  be  done  in  such  a  maimer  that  it  does  not  create  a 
whole  new  level  of  non-value-added  tasks  for  the  user  to  learn  and  perform.  Central  to  this 
concept  is  the  notion  that  the  product  developer  typically  could  be  described  as  a  "casual  user"  of 
the  EDN;  that  is,  the  product  developer  spends  the  majority  of  his  effort  on  tasks  directly  relating  to 
the  product,  and  only  uses  the  EDN  as  an  adjunct  to  his  primary  duties.  This  user  also  typically 
expects  a  high  level  of  sophistication  in  the  "user  friendly"  aspects  of  the  tool,  and  he  will  not 
easily  accept  a  tool  that  is  not  intuitive  to  use.  The  EDN  interface,  shown  in  Figure  5,  needed 
improvements  in  efficiency  of  use.  In  order  to  achieve  the  desired  capabilities  of  the  EDN, 
Westinghouse  recommends  that  a  structured  requirements  analysis  approach  be  done  using  one  of 
the  commonly  used  methodologies,  such  as  Quality  Function  Deployment  (QFD),  to  determine  if 
alternate  implementation  schemes  can  provide  a  much  higher  level  of  value  to  the  EDN. 
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Figure  5.  EDN  Interface. 


3. 1.3.2  Aster*X  EDN 

This  section  describes  the  unit  level  evaluation  of  the  Aster*X  EDN  software.  The  evaluation 
consisted  of  integrating  Aster*X  EDN  into  the  design  environment  and  using  it  to  capture  much  of 
the  design  data  for  the  pilot  project  Aster*X  EDN  was  also  used  to  produce  the  evaluation  reports 
for  other  DICE  tools. 

The  Aster*X  EDN  software  was  provided  to  the  Westinghouse  DICE  environment  as  part  of  the 
Concurrent  Engineering  Workstation  (CEW)  software  developed  by  GE/CRD.  The  CEW  is  a 
collection  of  tools  to  help  with  engineering  design  and  documentation  and  runs  on  Unix 
workstations.  The  CEW  is  integrated  into  the  Aster*X  software  package  from  Applix.  Aster*X 
contains  a  word  processing  module,  a  graphics  module,  a  spreadsheet  module,  a  mail  module, 
many  filter  modules,  and  macro  programming  capability.  The  CEW  software  is  made  up  of 
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several  software  modules  and  takes  maximum  advantage  of  the  Aster*X  macro  programming 
capability  to  perform  many  of  its  functions.  The  core  modules  are  the  CEW,  Aster*X  Toolkit,  and 
external  function  modules.  These  core  modules  provide  the  concurrent  engineering  framework  for 
integrating  the  actual  tools  and  services  used  by  the  design  engineer. 

The  scenario  for  this  evaluation  was  that  each  of  the  team  members  used  this  EDN  to  capture  all  the 
data  generated  from  completing  each  design  task.  However,  because  the  CEW  environment,  in 
particular  the  EDN  module,  was  tailored  to  the  GE  environment,  Westinghouse  found  that  many  of 
the  features  of  this  tool  were  not  applicable  to  the  pilot  project  designers'  tasks.  The  majority  of 
the  output  data  from  these  tasks  was  captured  in  the  Words  and  Spreadsheet  modules.  The  data 
was  then  easily  shared  among  the  team  members  by  using  the  Aster*X  tool 

The  conclusions  of  the  Aster*X  EDN  evaluation  are  that  the  Aster*X  EDN  has  similar 
requirements  for  improvement  as  die  Framemaker  EDN.  Most  significantly,  both  versions  of  EDN 
require  a  whole  new  level  of  tasks  for  the  user  to  learn  and  perform.  Also,  the  basic  commercial 
packages  on  which  the  EDNs  are  built  have  limitations;  e.g.,  Aster*X  provides  spreadsheet 
capability,  but  not  automatic  table  generation  capability,  whereas  Framemaker  provides  just  the 
opposite.  In  some  cases  the  Aster*X  software  is  not  as  reliable  as  Framemaker  (for  instance, 
significant  bugs  exist  in  the  Graphics  module).  The  recommendations  mentioned  in  section 
3.1.3.1  for  the  Framemaker  EDN  apply  to  the  Astcr*X  EDN. 

3.1.4  Communications  Manager  (CM) 

The  Communications  Manager  service  was  installed  as  part  of  the  DICE  environment  to  support 
background  processes  for  the  Project  Coordination  Board  (PCB).  The  purpose  of  the  tool  is  to 
simplify  remote  process  management  and  communications.  An  in-depth  evaluation  of  the  tool  was 
completed  during  DICE  Phase  4.  The  evaluation  scenario  included  the  use  of  the  CM  with  the 
PCB  and  through  a  command  line  interface.  The  comprehensive  discussion  of  the  evaluation  is 
found  in  the  report  submitted  on  this  contract  entitled  "Communications  Manager  (CM)  Evaluation 
Report "  [4],  submitted  separately  on  this  contract.  A  summary  of  this  evaluation  is  given  below. 

Four  versions  of  the  CM  were  delivered  to  Westinghouse  and  installed  during  this  phase  of  DICE. 
Installation  required  the  help  of  CERC  personnel,  as  the  CM  required  the  tailoring  of  CM  code  and 
recompilation.  Westinghouse  recommended  that  the  software  should  be  designed  so  site- specific 
information  can  be  entered  through  a  procedure  running  a  graphical  user  interface,  and  then  be 
accessed  by  the  application  from  that  procedure.  Once  installed,  software  products  should  not 
require  code  changes  and  recompilation.  Having  to  hard  code  information  into  an  application 
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complicates  maintenance  and  configuration  control,  and  requires  additional  effort  at  installation 
each  time  a  new  version  is  released. 

Several  general  areas  requiring  improvements  were  identified  during  the  evaluation  period.  For 
instance,  maintenance  issues  need  to  be  addressed  for  the  CM.  File  naming  and  management  are 
cryptic  and  complex,  and  even  the  support  personnel  from  CERC  had  difficulty  determining  the 
function  of  some  modules  and  what  constraints  existed.  A  naming  convention  needs  to  be  defined 
which  will  indicate  relationships  between  modules  as  well  as  the  function  of  the  module.  This  will 
help  with  configuration  control,  debugging,  and  code  maintenance. 

Other  maintenance  areas  which  should  be  improved  are  error  messages  and  housekeeping. 
Investigating  the  cause  of  errors  was  very  time  consuming  and  therefore  costly.  Informative  error 
messages  need  to  be  generated  when  problems  occur.  An  extensive  housekeeping  problem  which 
occurred  was  that  die  CM  generates  empty  directories  and  unneeded  files.  There  is  no  mechanism 
in  the  CM  code  which  automatically  eliminates  the  files  and  directories  that  are  generated.  These 
files  and  directories  add  additional  complexity  to  the  required  directory/file  structure,  and  take  up 
space  and  file  header  locations.  Determining  which  files  are  valid  and  being  used  becomes  more 
difficult  as  the  number  of  files  grows.  This  makes  maintenance  more  difficult  and  requires  the  tune 
of  the  systems  support  personnel  in  cleaning  up  the  directory  structure. 

Installation,  use,  and  maintenance  would  be  improved  by  adding  additional  information  to  the 
current  documentation.  In  addition,  errors  and  obsolete  information  that  currently  exist  in  the 
documentation  should  be  eliminated.  The  documentation  needs  to  outline  the  constraints  inherent 
in  the  CM,  give  a  description  of  the  information  provided  in  error  messages,  and  provide  a  higher 
degree  of  technical  information  for  the  systems  support  personnel  Documentation  is  a  critical  part 
of  the  successful  use  of  any  tool  and  should  be  a  high  priority  to  achieve  correctness  and 
thoroughness. 

In  summary,  die  conclusions  and  recommendations  from  the  CM  evaluation  are: 

•  The  overall  results  indicated  that  the  CM  adds  an  undesirable  level  of  complexity  to  process 
management  and  communications. 

•  The  Sun  operating  system  already  provides  primitives  which  support  the  activities  handled  by 
the  CM. 

•  Code  in  the  CM  which  duplicates  the  operating  system  primitives  should  be  removed  from 
the  CM. 
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•  The  use  of  socket  abstraction  in  the  CM  does  not  appear  to  have  simplified  interprocess 
communication. 

•  The  large  number  of  subprocedure  calls  required  of  developers  for  inclusion  of  the  I/O 
routines  and  error  message  handling  means  complexity  has  been  added  rather  than  removed 

•  The  approach  to  providing  communication  services  provided  by  the  CM  should  be  re¬ 
evaluated  and  incorporated  into  the  PCB,  if  possible,  to  simplify  operations. 

3.2  DICE  CONCURRENT  ENGINEERING  ENVIRONMENT  DEVELOPMENT 

To  conduct  the  pilot  project,  Westinghouse  developed  a  design  environment  incorporating  the 
DICE  technology.  This  section  describes  the  results  of  implementing  this  environment  The 
Westinghouse  integration  strategy  for  an  electronic  concurrent  engineering  environment  includes 
complete  access  from  an  existing  corporate  wide  network.  The  Westinghouse  Electronics  Systems 
Group  has  a  very  extensive  complement  of  legacy  equipment  that  includes  a  large  base  of 
VAX/VMS  systems,  PCs,  Macintoshes,  Apollo  workstations  using  Mentor  Graphics,  UNIX 
based  systems,  and  a  number  of  other  systems.  The  existing  Westinghouse  corporate  network  can 
permit  collocation  of  engineers  and  offer  the  DICE  software  as  a  network  service  which  would  be 
accessible  by  multiple  disciplines  scattered  throughout  the  corporation. 

The  environment  implemented  on  DICE  consisted  of  four  primary  elements:  (1)  software, 
consisting  of  the  DICE  application  software,  existing  Westinghouse  design  tools,  commercial 
design  software,  and  support  software  such  as  operating  systems,  (2)  hardware,  including  a  wide 
variety  of  workstations,  personal  computers,  and  mainframes,  (3)  networks,  including  general 
purpose  networks  such  as  the  Westinghouse  ethemet  system  and  local  rings  such  as  used  by 
Apollo  workstations,  and  (4)  the  integration  of  the  various  software  tools.  Implementing  the  DICE 
technology  in  this  environment  was  the  first  time  many  of  these  tools  were  applied  outside  of  the 
DICE  development  environment,  and  during  this  activity  a  number  of  recommendations  which  can 
impact  future  application  of  DICE  were  developed.  The  following  sections  describe  the 
environment  development  activities  performed  on  the  Phase  4  contract  and  provide  guidelines  for 
future  environment  implemented,  as  well  as  recommendations  for  improvement 

3.2.1  Software 

The  Westinghouse  design  environment  contains  a  wide  variety  of  software,  and  is  believed  to  be 
typical  of  a  large  electronics  development  company.  The  focus  of  the  pilot  project  was  the 
evaluation  of  the  impact  of  the  DICE  technology,  but  for  this  evaluation  to  be  in  the  proper  context 
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of  a  "real  life"  industrial  environment,  a  large  amount  of  additional  software  is  required  to  perform 
a  design  activity.  The  various  categories  include  the  DICE  software  itself,  commercial  design  tools 
currently  in  use  at  Westinghouse  for  the  design  activity,  in-house  specialty  design  tools,  and  the 
support  software  necessary  for  the  operation  of  the  system.  A  listing  of  the  software  necessary  for 
the  pilot  project  is  shown  in  Table  1. 


Table  1.  Software  in  the  Westinghouse  DICE  Environment. 


Software 

Function 

Developer 

Electronic  Design  Notebook 

DICE  Design  Notebook 

GE/CRD  (DICE) 

Concurrent  Eng.  Workstation 

DICE  Tool  Kit  including  EDN 

GE/CRD  (DICE) 

Project  Coordination  Board 

Product  and  Process  Access 

CERC  (DICE) 

Communications  Manager 

Communication  Services 

CERC  (DICE) 

Meeting  on  die  Net 

Networked  Meetings 

CERC  (DICE) 

Eramemaker 

EDN  Base  Software 

Frame  Technology  Corp. 

Aster*X 

CEW/EDN  Base  Software 

Applix,  Incorporated 

SunOS  4.1.1 

Operating  System  For  Sun 

Sun  Microsystems,  Inc. 

XI 1  Release  4 

X  Window  Software 

Massachusetts  Inst,  of  Tech. 

OSF/Motif 

X  Window  Software 

Integrated  Computer  Solutions 

Mentor  Design  Software 

Electronics  CAD  Tool  Suite 

Mentor  Graphics 

IPEX 

Expert  System  Design  Aid 

Westinghouse 

Nexpert 

Expert  System  Shell 

Neuron  Data,  Inanporated 

A  summary  description  of  these  various  software  elements  with  pertinent  observations  on  their 
usage  in  the  pilot  project  environment  follows: 
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•  DICE-Developed  Software:  The  DICE  software  resident  in  the  environment  consisted  of  the 
Framemaker-based  Electronic  Design  Notebook,  the  Aster*X-based  Electronic  Design  Notebook 
and  Concurrent  Engineering  Workstation  toolkit,  the  Project  Coordination  Board,  Meeting  on  the 
Net,  and  the  Communications  Manager.  This  software  was  continually  evolving  and  improving 
with  a  number  of  changes  being  included  in  each  release,  and  multiple  releases  were  received 
during  this  phase  of  DICE.  A  description  of  the  experiences  and  recommendations  on  each  of 
these  was  given  in  Section  3.1.1. 

One  additional  aspect  pertaining  to  all  the  DICE  software  as  a  whole  was  that  tool  access  by  die  end 
users  was  initially  quite  complicated.  Each  tool  was  executed  using  a  defined  name  and  path,  and 
often  required  completion  of  several  steps  preceding  the  actual  program  execution.  The  users 
required  a  more  sophisticated  and  user  friendly  means  for  working  with  the  DICE  tools.  CERC 
assisted  in  the  solution  by  developing  the  DICE  Generic  Services  Interface  (GSI).  This  graphical 
tool  interface  had  a  configuration  tile  to  allow  system  support  personnel  to  build  or  alter  a 
customized  environment  in  addition  to  updating  each  of  the  user’s  paths.  After  the  initial  setup 
work,  it  greatly  improved  user  access.  Because  this  interface  uses  a  precompiled  program  to 
display  options,  it  is  not  as  flexible  as  it  should  be  to  alter  all  screen  options.  However,  it  was  an 
excellent  initial  step  to  simplify  DICE  tool  user  access.  Westinghouse  recommends  that  this 
interface  be  maintained  and  improved  upon  to  increase  the  efficiency  in  starting  the  DICE  tocds. 

•  Framemaken  The  DICE  Electronic  Design  Notebook  operates  as  a  layer  of  software  on  top  of  a 
commercial  software  application  program  called  Ffamemaker,  which  is  a  desktop  publishing 
package.  This  third  party  program  was  relatively  simple  to  install  and  required  a  minimum  of 
reconfiguration  of  the  user’s  startup  procedures  (i.e.,  .eshre  files).  Although  the  tool  had  its  own 
tutorial,  which  was  well  done,  users  found  aspects  of  this  package  difficult  to  use  and  understand, 
and  significant  time  was  spent  helping  Users  become  more  comfortable  with  this  software.  An 
important  conclusion  from  this  is  that  any  software  development  effort  built  on  top  of  other 
commercial  software  must  consider  the  merits  of  the  underlying  software  carefully  when  making 
die  selection.  Another  issue  that  arose  was  that  a  strategy  needs  to  be  developed  to  remain 
compatible  with  upgrades  of  the  underlying  commercial  software  when  applying  this  approach. 
The  EDN  was  developed  on  Phase  3  using  one  version  of  Framemaker,  and  for  Phase  4, 
Westinghouse  had  licensed  the  newer  version  which  had  recently  been  released.  Although  the 
EDN  software  was  compatible  with  the  newer  version,  a  great  potential  for  problems  exists  unless 
a  close  relationship  is  developed  with  the  commercial  software  developer. 
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*  Aster*X:  During  the  third  quarter  of  DICE  Phase  4,  the  decision  was  made  to  migrate  to  a 
second  version  of  the  EDN,  in  light  of  the  difficulties  experienced  by  the  end  users  in  working 
with  the  Framemaker  portion  of  the  EDN.  During  the  evaluation,  it  had  been  determined  that 
Framemaker  was  a  powerful  desktop  publishing  tool  which  was  more  complicated  than  necessary 
to  support  the  simpler  engineering  documentation  tasks  typically  required  by  the  pilot  project 
concurrent  engineering  team.  The  second  version  of  the  EDN  used  a  software  package  called 
Aster*X  (Version  2.0),  which  provided  a  simpler  to  use  word  processor  as  well  as  an  integrated 
spreadsheet  and  drawing  package.  However,  the  transition  to  EDN  using  Aster*X  was  not 
problem  free,  due  to  basic  limitations  in  this  software.  The  Aster*X  file  import  and  export 
functions  became  disabled  during  the  migration,  which  prevented  data  flow  to  and  from 
Framemaker  and  also  inhibited  Macintosh  use.  Additional  problems  included  poor  graphics 
integration  into  the  Aster*X  word  processor.  For  example,  the  only  way  to  create  tables  was  to 
use  the  graphics  option,  which  then  meant  that  there  was  no  spell  checking  capability  available. 
The  team  members  using  the  Aster*X  EDN  also  experienced  several  crashes  with  the  Aster*X 
software,  caused  by  the  failure  of  the  zoom  command.  According  to  Applix,  the  developers  of 
Aster*X,  the  problems  identified  in  the  Westinghouse  DICE  environment  will  be  resolved  with 
their  new  release  of  Version  2.1. 

•  Operating  Systems:  The  DICE  technology  is  based  on  the  Unix  operating  system,  and 
maintaining  compatibility  between  the  operating  system  versions  and  the  application  software  was 
a  continuing  issue.  The  Sparcstation  1  workstations  used  on  Phase  3  contained  the  SUN 
operating  system  SUNOS  4.0.3.  The  DICE  software  development  effort  was  migrating  to 
SUNOS  4.1.1  in  Phase  4,  requiring  an  update.  Due  to  certain  limitations  of  Sun  Microsystems' 
installation  procedure,  the  support  personnel  found  that  the  use  of  the  workstation's  internal  dual 
104  MegaByte  (MB)  drives  was  constraining  for  system  partition  storage  requirements.  Because 
of  this  partition  constraint,  reconfiguration  of  system  software  was  more  time  consuming  than  it 
typically  would  take.  Therefore,  Westinghouse  recommends  larger  internal  disk  drives  for  the 
local  storage  for  a  machine  expected  to  support  DICE  tools.  The  end  result  of  the  upgraded 
operating  system  and  extension  of  paging  areas  was  improved  system  responsiveness.  With  the 
improvements  experienced  thus  far  by  incorporating  operating  system  upgrades,  Westinghouse 
encourages  the  incorporation  of  Solaris  2.0  as  a  foundation  operating  system  for  DICE  tool 
development  during  Phase  5.  This  is  in  alignment  with  Sun  Microsystems'  progression  of  their 
operating  system. 

The  Network  File  System  (NFS)  capability  in  the  operating  system  was  used  to  provide  network 
access  to  the  tools.  This  permitted  storing  the  tools  on  one  large-disk  system  and  providing  access 
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from  the  workstations  which  were  not  directly  connected  to  the  hard  disk.  This  provided  tool 
availability  without  requiring  storage  of  the  tools  on  multiple  machines.  Configuring  the  system  in 
this  manner  resulted  in  reduced  costs  for  tool  storage  by  reducing  the  demands  of  secondary 
memory  storage  requirements  in  the  individual  machines.  The  final  configuration  contained  a 
single  Sparestation  1  workstation  acting  as  an  NFS  and  mail  server.  A  second  node  acted  as  the 
Network  Information  Services  (NIS,  formerly  yellow  pages)  for  the  DICE  collection  of  nodes. 
The  server,  in  addition  to  handling  processes  for  other  workstations,  was  used  as  a  work  platform 
for  other  engineers. 

•  Window  Software:  The  baseline  window  management  system  for  the  Westinghouse  DICE 
environment  was  the  XI 1  Release  4  software  developed  by  MIT.  CERC  support  was  especially 
helpful  in  configuring  X  files  so  that  library  modules  were  complete  for  DICE  tool  needs. 
Westinghouse's  final  window  configuration  included  installing  the  Motif  window  software  as 
well.  Since  optimization  and  patches  for  XI 1  Release  4  are  available  with  XI 1  Release  5, 
Westinghouse  encourages  the  pursuit  of  incorporation  of  the  latest  version  of  the  XI 1  software  for 
the  next  phase  of  DICE. 

•  Mentor  Graphics:  The  primary  electronic  design  CAD  software  currently  used  at  Westinghouse 
is  the  package  of  design  tools  provided  by  Mentor  Graphics.  This  software  contains  a  number  of 
applications  allowing  schematic  capture,  circuit  simulation,  and  layout  Westinghouse  currently 
uses  Versions  7.0  and  7.1,  which  are  of  the  "closed  architecture"  type.  This  was  a  major  inhibitor 
to  efforts  to  integrate  it  with  other  tools.  A  new  version,  8.0,  is  in  the  initial  release  stages,  but  its 
maturity  was  not  deemed  sufficient  for  incorporation  into  the  DICE  environment  at  the  start  of 
Phase  4.  The  new  version  is  claimed  to  be  an  open  architecture,  which  may  ease  some  of  the 
integration  issues.  The  Mentor  software  presently  resides  on  a  large  number  of  Apollo 
workstations  in  the  Westinghouse  environment,  and  runs  under  the  Apollo  operating  system  called 
Aegis.  The  versions  of  this  operating  system  currently  in  use  are  10.1  and  10.3. 

•  IPEX/Nexpert:  The  Integrated  Product  Engineering  Expert  (IPEX)  developed  on  DICE  Phase  3 
is  a  software  tool  designed  to  improve  quality  and  reduce  cycle  time  by  providing  information 
which  is  typically  available  only  to  the  manufacturing  and  process  engineers  to  the  other  designers 
of  a  product  The  function  of  the  IPEX  is  to  provide  design  and  manufacturing  engineers  with  a 
tool  to  serve  as  a  intelligent  repository  of  the  knowledge  base  regarding  Low  Temperature  Cofired 
Ceramic  (LTCC)  materials  used  for  multichip  modules  used  on  high  performance  electronics.  The 
tool  allows  the  user  to  navigate  the  knowledge  base  and  receive  information  and  advice  on  various 
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design  and  manufacturing  considerations  in  a  concurrent  engineering  environment  The  IPEX 
operates  within  an  expert  shell  system  called  Nexpert,  which  was  created  by  Neuron  Systems,  Inc. 

3.2.2  Hardware 

The  hardware  environment  implemented  on  DICE  was  configured  to  be  a  small  scale  representation 
of  an  eventual  wide  area  implementation.  In  this  manner,  issues  could  be  identified  and  resolved  in 
an  environment  representative  of  the  final  implementation,  yet  due  to  the  small  number  of  nodes  in 
the  environment  problem  solving  could  be  kept  manageable. 

The  DICE  software  was  developed  by  CERC  and  GE/CRD  on  the  most  recent  pieces  of 
equipment  which  have  high  performance  ratings  and  a  minimum  of  16  MB  of  memory.  When  the 
individual  tools  are  hosted  and  executed  concurrently,  file  access  and  network  responses  of  the 
individual  platforms  are  stressed.  As  the  DICE  tools  suite  becomes  more  integrated,  performance 
requirements  will  continue  to  grow.  These  issues  impacted  the  hardware  environment  and  have 
required  an  evolution  of  the  DICE  environment  to  one  significantly  different  from  the  environment 
at  the  start  of  Phase  4. 

The  Phase  4  environment  started  with  three  computer  platforms  for  hosting  the  DICE  software, 
each  of  which  was  a  Sun  Microsystems  Sparcstation  1  with  8  MB  of  RAM  and  with  two  Quantum 
104  MB  drives.  This  provided  a  total  of  208  MB  of  local  internal  storage  capacity.  An  additional 
Sparcstation  1  was  added  to  the  environment  in  the  first  quarter  of  Phase  4  as  an  additional 
working  location  for  the  DICE  pilot  project  team.  All  systems  were  connected  by  thickwire 
ethemet  which  provided  access  to  the  Westinghouse  VAX/VMS  and  VAX  ULTRIX  systems  as 
well  as  the  Apollo/Mentor  systems,  PC's,  and  Macintosh  computers. 

The  storage  requirements  of  the  DICE  tools  being  hosted  in  the  environment  was  greater  than 
could  be  managed  with  the  internal  storage  available  on  the  workstations.  A  1.2  Gigabyte  Hewlett 
Packard  Coyote  hard  disk  drive  was  added  to  the  environment  to  provide  adequate  storage  space. 
This  Small  Computer  Standard  Interface  (SCSI)  disk  drive  was  exported  from  a  single  system  to 
other  networked  nodes  using  Network  File  System  (NFS)  services. 

Initially,  the  external  SCSI  disk  drive  was  serving  diskless  clients  in  a  configuration  originally 
defined  at  the  beginning  of  Phase  4.  This  was  done  in  an  effort  to  retain  the  existing  system  disk 
configurations  and  at  the  same  time  provide  for  the  needs  of  the  tools  developed  by  CERC  and  GE 
The  DICE  environment  experienced  many  problems  with  poor  performance  of  the  tools,  poor 
system  responsiveness  and  slow  network  access.  The  decision  was  made  to  reconfigure  local 
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drives  as  a  means  of  improving  performance  while  retaining  local  SUNOS  and  swap  areas. 
Locally  served  disk  storage  improved  file  availability  and  access  times  for  the  DICE  tools. 

Additional  enhancements  were  made  to  the  environment  during  the  course  of  die  pilot  project  All 
Sparcstation  1  systems  were  upgraded  to  include  12  MB  of  local  RAM.  Response  time  and  tool 
performance  continued  to  be  slow,  as  the  need  to  manage  multiple  network  accessing  and  the 
transfer  of  files  and  data  stressed  the  hardware  to  the  fullest  In  some  instances,  response  time  was 
so  poor  that  the  tools  were  timing  out  and  failing.  Continuing  efforts  were  made  to  address  system 
performance  and  responsiveness. 

As  part  of  the  effort  to  improve  performance,  a  Sparcstation  2  was  evaluated.  Performance  metrics 
were  gathered  for  the  original  DICE  configuration  and  again  with  the  inclusion  of  the  Sparcstation 
2.  A  significant  improvement  in  performance  was  measured  with  the  Sparcstation  2  in  place,  with 
an  average  of  30%  improvement  in  response  time  using  the  Sparcstation  2  being  realized.  Based 
on  the  response  and  performance  improvement  experienced  in  the  environment,  a  Sparcstation  2 
was  incorporated  in  die  environment  as  a  file  server. 

Only  a  limited  number  of  hardware  failures  were  encountered  during  Phase  4.  One  occurred  when 
a  Sparcstation  1  had  internal  disk  head  parking  adhesive  failure,  although  Westinghouse  was  able 
to  recover  the  drive.  Other  less  critical  hardware  problems  were  often  able  to  be  cleared  with  a 
simple  power  cycle  of  the  affected  system.  Westinghouse  also  experienced  a  significant  number  of 
write  failures  to  the  Sun  quarter-inch  tape  drive.  This  older  type  of  media  and  tape  drive  meant  that 
several  hours  and  the  handling  of  several  tapes  were  involved  with  system  backups  for  each 
partition.  Additionally,  the  installation  of  new  versions  of  software  required  more  time  than 
necessary.  An  8MM  tape  subsystem  was  implemented  as  a  way  of  addressing  this  problem.  Also 
due  to  Sun’s  policy  to  distribute  software  now  on  Compact  Disk  (CD)  only,  a  CD  reader  was 
added.  The  addition  of  these  auxiliary  pieces  of  equipment  significantly  improved  the  time 
required  for  installation  of  new  software,  maintaining  the  environment  and  doing  backups  of  the 
systems. 

The  final  DICE  lab  configuration  consisted  of  five  associated  Sparcstation  1  ’s  and  a  Sparcstation  2 
which  provides  an  additional  1.3  GB  drive  with  the  original  1 GB  drive.  The  Sparcstation  2  also 
serves  with  an  8 MM  tape  subsystem,  a  CD  reader,  and  an  Apple  LaserWriter.  Access  to  the  Sun 
quarter  inch  tape  subsystem  is  included  as  well.  This  configuration  is  shown  in  Figure  6. 
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Figure  6.  Phase  4  DICE  Laboratory  Configuration. 

Several  lessons  were  learned  from  the  development  and  maintenance  of  the  DICE  environment  in 
Phase  4.  It  is  critical  that  it  is  understood  by  all  users  of  the  DICE  tools  and  services  that  the 
software  cannot  be  hosted  cm  equipment  other  than  the  latest  generation.  Part  of  die  Westinghouse 
pilot  site  evaluation  was  to  determine  wide  scale  implementation  issues,  such  as  whether  or  not  the 
DICE  environment  could  be  built  using  typically  available  equipment  The  result  of  this  effort 
clearly  indicates  that  a  sizable  investment  in  equipment  is  required  for  the  efficient  use  of  die  DICE 
concurrent  engineering  capabilities. 
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Environment  specifications  must  be  determined  and  provided  to  prospective  users  of  the  DICE 
tools  suite,  along  with  a  strong  recommendation  that  manufacturer  supplied  hardware  maintenance 
be  available.  The  definition  of  usage  specifications  provided  to  future  implementations  should 
include  the  minimum  amount  of  RAM  and  hard  disk  storage  required  to  host  and  run  the  tools,  die 
performance  capabilities  of  the  platform  acting  as  the  server,  the  amount  of  swap  space  required  by 
the  different  tools,  and  the  level  of  file  and  database  access  for  each  tool  so  network  usage  can  be 
addressed.  These  specifications,  as  well  as  example  configurations,  should  be  provided  to 
organizations  planning  cm  implementing  a  concurrent  engineering  environment  using  all  or  part  of 
the  DICE  tools  suite. 

3.2.3  Networks 

Network  connectivity  is  a  key  element  of  a  computer  based  CE  environment.  The  Sun 
Sparcstation  nodes  in  the  Westinghouse  environment  are  interconnected  using  thickwire  ethemet. 
All  present  Sparcstation  connections  use  TCP/DP  protocol  and  are  connected  to  the  Westinghouse 
"open"  network  permitting  access  between  other  necessary  internal  systems  such  as  Apollo 
workstation  and  personal  computers.  The  network  bandwidth  did  not  prove  to  be  a  performance 
limiter  in  the  small  environment  implemented  cm  die  pilot  project,  as  all  communication  was  within 
the  local  Westinghouse  Electronics  System  Group  Baltimore  region.  However,  connection  to 
remote  locations  such  as  the  Westinghouse  Central  Research  Laboratories  in  Pittsburgh  required  a 
high  bandwidth  link,  such  as  a  T1  line. 

An  important  aspect  of  Westinghouse ’s  network  configuration  is  that,  like  many  industrial 
enterprises,  it  is  isolated  from  direct  connection  to  external  communication  networks  such  as  the 
Internet  The  isolation  mechanism  allows  non-realtime  access  such  as  electronic  mail,  but  prevents 
interactive  access  from  the  outside.  Defense  facilities  are  very  security  conscious  and  have  found 
network  isolation  such  as  this  to  be  helpful  in  deterring  undesirable  external  network  access.  This 
policy  can  be  a  hindrance  for  optimal  data  transfer  with  a  lack  of  direct  connectivity  to  external 
sites.  Westinghouse  recommends  that  future  DICE  activities  address  security  measures  which  can 
enable  corporate-to-corporate  or  corporate-to-university  direct  connectivity. 

3.2.4  Integration 

The  Westinghouse  DICE  pilot  project  integration  effort  focused  on  incorporation  of  the  DICE  tools 
onto  the  workstations  in  place  in  the  DICE  lab  at  Westinghouse.  Additional  efforts  were 
performed  to  integrate  the  DICE  suite  with  the  existing  design  tools  at  Westinghouse.  However, 
full  scale  integration  of  the  DICE  tool  suite  was  not  possible  due  to  the  immature  state  of  the  tools. 
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It  had  been  hoped  that  this  phase  of  DICE  would  produce  a  seamless  set  of  concurrent  engineering 
tools  and  services  which  could  be  evaluated  as  an  integrated  whole.  When  it  became  obvious  that 
this  would  not  be  possible,  each  tool  was  evaluated  for  its  readiness  to  be  integrated  with  any  other 
tool  or  service  in  the  environment  where  benefits  from  the  integration  could  be  derived.  The  tools 
actually  used  in  the  pilot  project  were  not  at  a  level  of  maturity  where  they  could  be  integrated,  and 
they  were  used  essentially  as  standalone  products,  accessed  over  the  network.  The  following 
discussion  describes  a  number  of  areas  where  tire  integration  features  need  to  be  improved. 

•  Third  Party  Data  Integration:  Design  engineers  use  a  number  of  third  party  CAD  tools  in  their 
development  activities.  What  was  critically  limiting  was  that  the  design  and  analysis  software  that 
was  necessary  for  these  engineers  could  not  effectively  be  tightly  integrated  with  any  of  the  DICE 
tools.  Furthermore,  the  critical  design  data  was  not  even  able  to  be  filtered  or  translated  into  these 
tools  or  back  out  from  the  tools,  as  the  DICE  software  provided  few  options  to  perform  importing 
and  exporting  of  information.  For  any  penetration  of  the  DICE  tools  into  the  design  domain,  data 
portability  is  critical  for  its  success. 

Particular  third  party  data  integration  problems  in  MONET  and  PCB  need  to  be  addressed.  The 
Westinghouse  team  had  anticipated  that  MONET  would  interface  with  the  Mentor  Graphics 
electronic  design  system  resident  on  the  Apollo  workstations  in  the  DICE  environment.  This 
capability  would  enable  direct  use  with  the  schematic  information  developed  on  the  Mentor 
software.  The  problem  of  the  poorly  designed  X-window  interface  of  the  Mentor  software  posed 
serious  limitations  to  the  ability  to  develop  the  interface  connections  between  the  Mentor  software 
and  MONET.  Although  Mentor  claims  to  be  X-window  based,  their  software  completely  controls 
the  screen  and  does  not  service  simultaneous  X  requests  from  another  process.  The  new  Mentor 
software  (Version  8.0)  claims  to  correctly  handle  such  requests. 

The  PCB  requires  a  separate  translation  tool  for  importing  Mac  Project  (a  commercial  program 
management  tool)  data  for  the  process  model.  CERC  created  the  a  translation  tool  to  enable 
Westinghouse  to  impart  pre-existing  data  into  the  PCB.  This  process  was  not  efficient  and  made 
the  setup  of  the  PCB  difficult  Other  problems  appeared  as  the  tool  was  used  across  the  range  of 
the  capabilities  provided;  e.g.,  the  PCB  once  corrupted  its  own  source  file.  In  this  case,  the  PCB 
failed  to  continue  to  function  or  even  read  tire  source  knowledge  base  once  a  record  created  during 
normal  program  use  was  improperly  stored. 

•  Interface  Integration:  An  additional  issue  in  integrating  the  DICE  tools  was  the  particular  interface 
used  during  tod  development.  For  instance,  the  EDN  is  a  layered  product  built  on  either  Aster*X 
or  Framemaker  commercial  software.  Framemaker  poses  a  particularly  difficult  problem  because 


Page  27 


Westing  house  Electronic  Systems  Group 


DICE  Phase  4  Final  Report 


the  interface  is  neither  removable  nor  tailorable.  Integration  between  the  layers  of  the  EDN  could 
not  be  fully  achieved  because  of  the  Framemaker  interface. 

•  Integration  and  Support  Expense:  The  DICE  environment  was  an  expensive  environment  to 
attempt  to  integrate  and  support.  Systems  support  personnel  found  that  supporting  the  DICE 
environment  required  a  variety  of  tasks  to  be  performed  which  were  not  normally  part  of 
maintaining  an  environment  Included  in  this  were  learning  the  functions  and  use  of  all  the  DICE 
tools  so  the  support  personnel  could  act  as  instructors  to  the  end  users.  Working  closely  with  the 
tool  developers  in  debugging  immature  software  was  also  part  of  the  effort  Updates  to  operating 
systems,  installing  and  supporting  layered  products  and  working  with  DICE  tool  developers  were 
efforts  which  had  to  be  carefully  coordinated  and  completed.  The  layered  products  like  the  EDN 
present  special  problems  for  the  users  and  result  in  additional  help  being  needed  from  the  systems 
support  personnel.  In  addition  to  these  tasks,  the  normal  maintenance,  network  issues, 
performance  issues,  and  backups  had  to  be  managed. 

User  development,  problems,  and  questions  were  the  most  time  consuming  portion  of  system 
support  time.  Approximately  40%  of  system  support  time  was  spent  on  these  types  of  issues. 
About  one  q  tarter  of  the  support  time  was  spent  on  software  installations,  and  another  quarter  was 
spent  on  administrative  details  such  as  backups  and  other  related  tasks.  Approximately  10%  of  the 
system  support  effort  was  spend  on  hardware  related  issues. 

A  significant  amount  of  time  was  spent  trying  to  acclimate  the  users  to  the  drastic  differences 
between  the  graphical  user  interfaces  of  the  tools.  Each  tool  had  a  unique  set  of  commands  and 
interfaces  which  created  confusion  for  the  users.  This  complicated  collection  of  DICE  software 
interfaces  could  be  improved  significantly  by  using  a  clean,  simple,  consistent  "lode  and  feel"  of  a 
well  developed  graphical  user  interface. 

Other  time  consuming  maintenance  issues  included  file  permissions  that  were  extended  too  broadly 
in  an  effort  to  achieve  critical  tool  functionality  which  should  be  permanently  corrected.  Significant 
improvements  in  on-line  help,  user  documentation,  automated  install  scripts,  file  access  controls 
and  improved  interfaces  are  also  anticipated  as  the  DICE  software  matures. 

•  Specialty  In-House  Tool  Integration:  During  the  latter  stages  of  the  pilot  project  design  activity,  a 
review  of  in-house  tools  and  services  used  by  the  engineers  across  the  product  lifecycle  was  made. 
These  tools  were  investigated  as  possible  candidates  for  integration,  possibly  using  the  GE/CRD 
wrappers  as  a  means  of  expediting  the  integration.  It  was  determined  that  several  are  potential 
candidates,  and  that  the  integration  should  be  pursued  under  DICE  Phase  5.  The  tools  identified 
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were  a  reliability  prediction  tool,  a  thermal  analysis  tool,  a  life  cycle  cost  estimator,  and  a  design  to 
cost  estimator. 

The  Integrated  Product  Engineering  Expert  software  developed  in  Phase  3  of  DICE  was 
integrated  into  the  DICE  environment  during  Phase  4.  On  Phase  3,  IPEX  used  a  manufacturing 
data  file  of  board  components  as  input  and  then  verified  this  data  against  Westinghouse  design 
guidelines  and  manufacturing  constraints  in  a  knowledge  base.  In  Phase  4,  the  team  selected  an 
engineering/manufacturing  application  for  which  the  necessary  data  was  available  which  would 
benefit  from  the  existing  IPEX  capabilities.  The  area  selected  was  the  design  and  manufacture  of 
Low  Temperature  Cofired  Ceramic  (LTCC)  substrates  used  in  multi-chip  modules.  The  effort 
involved  in  the  integration  of  the  IPEX  tool  into  LTCC  design  and  manufacturing  included 
rehosting  IPEX  as  a  multi-user  tool  accessible  over  the  network,  coordinating  information  access 
with  the  current  LTCC  environment,  and  training  the  users  in  die  use  of  IPEX. 

In  summary,  a  high  level  of  integration  of  the  DICE  tools  would  be  a  means  of  providing  a 
seamless  environment,  reducing  the  number  of  interfaces  accessed  by  the  users,  and  reducing  the 
time  required  for  the  engineer  to  work  within  the  concurrent  engineering  environment  The  lack  of 
maturity  of  the  DICE  tools  resulted  in  the  level  of  effort  being  directed  at  continuing  improvement 
of  the  stand  alone  version  of  the  software  rather  than  pursuing  integration  activities.  The  results  of 
the  tool  evaluation  effort  indicated  that  most  of  the  tools  in  their  present  implementation  did  not 
provide  sufficient  improvement  in  supporting  concurrent  engineering  in  the  environment  to  warrant 
an  integration  effort  It  was  concluded,  however,  that  an  integrated  environment  is  critical  to  the 
success  of  computer  supported  concurrent  engineering  environments.  Careful  selection  of  tools 
and  services  is  critical,  and  selection  criteria  should  encompass  both  concurrent  engineering 
capabilities  and  ease  of  integration. 


3.3  PILOT  PROJECT  DESIGN 

The  primary  objective  of  the  Pilot  Project  Design  was  to  assess  and  validate  the  benefit  of  the  DICE 
technology  when  used  to  enable  computer  based  concurrent  engineering.  Another  objective  of  the 
Pilot  Project  Design  was  to  provide  additional  feedback  to  the  CERC  Test  Bed  and  the  respective 
software  developers  concerning  modifications  required  on  this  technology  to  improve  its 
effectiveness  in  the  design  process.  The  major  aspects  of  the  pilot  project  consisted  of  defining  the 
product  and  modeling  it,  identifying  improvements  to  the  development  process  and  the  team 
organization,  developing  the  metrics  to  be  used,  and  measuring  the  resulting  effect  on  the  process. 
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The  design  product  chosen  was  a  signal  processor  module  called  die  SPX-32  Floating  Point  Signal 
Processor  Module  (SPM/FP).  The  development  process  selected  was  based  on  Westinghouse’s 
Integrated  Product  Development  Team  (IPDT)  guide  that  was  recently  developed  under 
Westinghouse's  TQM  program,  and  which  has  been  adopted  for  use  on  new  development  projects 
such  as  the  F-22  radar.  This  process  was  examined  for  improvement  areas,  and  assessments  were 
made  as  to  where  the  DICE  technology  could  have  an  impact 

The  DICE  tools  used  by  the  pilot  project  designers  included  the  Electronic  Design  Notebook,  the 
Project  Coordination  Board,  and  the  Meeting  On  the  Network.  The  Communications  Manager  also 
was  used  to  perform  background  services  for  the  PCB,  but  its  operation  was  transparent  to  the 
pilot  project  team  designers.  The  pilot  project  design  was  performed  within  a  design  scenario 
context  by  a  multidisciplined  team  of  engineering  functions  (system,  electrical,  mechanical, 
manufacturing,  and  supportability  engineering)  who  exercised  the  DICE  tools  for  the  design  of  the 
SPM/FP  product  using  die  IPDT  process. 

The  case  history  of  the  pilot  project  is  described  in  the  following  sections.  Section  3.3.1  describes 
the  product  and  Section  3.3.2  describes  the  development  process  and  the  team  organization.  The 
metrics  used  and  the  process  of  selecting  them  are  found  in  Section  3.3.3,  and  the  overall  pilot 
project  results  are  discussed  in  Section  3.3.4. 

3.3.1  Pilot  Project  Product  Description 

The  cost  of  the  electronics  in  military  systems  has  increased  to  become  a  major  element  of  the 
development,  production,  and  support  costs  over  die  life  of  the  systems.  Programmable  digital 
electronics  has  become  a  major  element  of  the  electronics  cost  as  more  and  more  of  the  system 
functions  are  automated  to  improve  sensing,  targeting,  and  navigation  performance  and  to  reduce 
operator  workloads.  The  pilot  project  product  was  chosen  to  be  representative  of  a  class  of  high 
performance,  high  value  digital  electronics  used  in  a  large  portion  of  today's  military  designs.  In 
this  way,  the  benefits  accruing  from  DICE  as  applied  to  the  electronics  pilot  project  would  have  a 
large  multiplier  effect  cm  a  large  number  of  similar  products. 

The  product  chosen  for  the  pilot  project  was  a  modular  processing  element  called  the  SPX-32 
Floating  Point  Signal  Processing  Module  (SPM/FP).  On  an  internally  funded  Westinghouse 
effort,  Westinghouse  systems  engineers  developed  a  specification  for  this  module  based  on  system 
requirements  for  emerging  programs  and  planned  product  improvements  for  systems  currently 
undo1  development  The  intent  of  this  module  was  to  provide  a  performance  capability  upgrade  by 
replacing  an  existing  processor  module  currently  used  cm  a  number  of  signal  processor  systems. 
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An  emphasis  was  also  placed  on  minimal  replacement  cost  impact,  and  a  number  of  constraints 
were  placed  on  the  design  to  allow  plug-in  compatibility  between  the  old  and  new  modules  to 
expedite  system  level  upgrades.  A  Critical  Item  Development  Specification  (commonly  called  a  B- 
2  level  specification  in  military  development  terminology)  was  developed  and  used  as  the  starting 
point  for  the  product  design.  This  procedure  provides  a  design  starting  point  which  is  identical  to 
large  scale  system  design,  in  which  the  system  is  described  by  a  hierarchy  of  specifications,  each 
of  increasingly  lower  level  detail. 


3.3.1. 1  Electronic  Module  Description 

The  SPM/FP  is  a  Line  Replaceable  Module  (LRM)  that  incorporates  the  standards  developed  by  the 
Joint  Integrated  Avionics  Working  Group  (JIAWG),  which  allow  standardized  electronics  modules 
to  to  reused  in  multiple  military  systems.  The  SPM/FP  contains  16  processing  nodes  that  contain  a 
32-bit  floating  point  signal  processor  device,  eight  megabytes  of  static  RAM  for  both  program  and 
data  memory,  a  control  and  data  interface,  and  a  test  interface. 

An  improved  architecture  was  also  incorporated.  This  new  design  supports  a  Multiple  Instruction, 
Multiple  Data  (MIMD)  architecture  for  flexibility  in  applications,  and  a  chordal  ring  network  for 
high  bandwidth  processor  node  to  processor  node  communication.  Figure  7  illustrates  these 
elements  and  their  connectivity. 

The  SPM/FP  design  conforms  to  the  current  electrical  interface  of  the  module  it  is  replacing.  The 
SPM/FP  will  support  a  dual  32-bit  data  interface,  a  single  16-bit  control  interface,  a  3-bit  test 
interface,  and  maintain  the  same  clock  speeds  and  power  and  ground  distribution.  The  SPM/FP 
conforms  to  the  current  mechanical  interface,  the  standard  connector  and  the  standard  SEM-E 
(Standard  Electronic  Module,  Revision  E)  board  dimensions  and  spacing  per  the  JIAWG 
standards. 

The  SPM/FP  uses  multichip  modules  (MCMs)  with  a  size  of  1.43  inches  by  1.45  inches  for  a  total 
of  18  MCMs  per  double  sided  SEM-E  module.  Figure  8  shows  the  partitioning  of  the  major 
functions  into  the  MCMs  and  a  general  layout  of  the  18-node  module.  The  new  design  will  utilize 
all  18  of  these  locations  (16  processing  node  MCMs,  1  Control  and  Data  Interface  MCM,  and  1 
Test  Interface  MCM). 
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Hgure7.  SPX-32  SPM  Elements. 


3. 3. 1.2  Product  Model 

To  take  advantage  of  the  potential  for  electronic  data  sharing  in  a  computer  based  concurrent 
engineering  environment,  the  concept  of  a  product  model  is  required.  Activities  in  developing 
standard,  neutral  data  format  product  models  are  underway  in  various  activities,  such  as  the 
Product  Data  Exchange  using  STEP  (PDES)  standards.  However,  these  standards  for  electronic 
products  are  not  as  developed  as  in  the  mechanical  arena,  so  Westinghouse,  in  collaboration  with 
CERC,  had  to  develop  a  product  model  representative  of  the  pilot  project  electronics  module.  The 
product  model  for  the  pilot  project  is  a  hierarchical  structure  of  all  the  design  requirements  and 
attributes  of  the  SPM/FP.  The  development  of  this  product  model  took  several  iterations,  and  a 
major  objective  was  to  make  the  model  template  usable  for  all  electronics  modules.  After  the  model 
was  created  in  graphical  form,  it  was  sent  to  CERC  for  coding  in  the  Express  data  definition 
language  and  placement  into  PCB  to  form  the  basis  for  the  PCB  product  model. 
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Since  the  development  of  product  models  is  not  yet  a  mature  procedure  and  there  is  lack  of 
standards  in  this  area,  the  model  development  process  was  a  trial  and  error  process  that  evolved 
from  experience  gained  from  the  development  of  military  avionics  electronics  products.  The  basis 
for  the  product  model  evolved  from  the  suggested  outline  for  B2  Specification  development  from 
MIL-STD-490A,  as  it  had  the  potential  to  cover  any  electronics  module  type.  From  this  starting 
point,  Westinghouse  designers  from  the  various  pilot  product  disciplines  began  to  embellish  the 
product  model  with  their  own  particular  needs  for  product  data.  After  each  discipline  provided 
their  respective  inputs,  all  the  design  aspects  including  electrical,  mechanical,  supportability  and 
manufacturing/producibility  were  arranged  in  a  hierarchical  structure.  Several  iterations  of  this 
process  occurred  in  order  to  interview  individuals  with  additional  experience  to  assure 
completeness  of  the  product  model. 
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The  product  model  organization  takes  the  principal  perspectives  of  die  design  and  breaks  them 
down  as  a  function  of  product  requirements.  The  result  is  a  hierarchical  structure  (top-down 
breakdown)  of  product  attributes  for  all  design  perspectives,  including  all  the  support  and 
manufacturing  aspects  of  the  detailed  design. 

The  model  structure  of  the  various  perspectives  and  requirements  for  all  disciplines  of  the  pilot 
project  design  is  shown  in  Figure  9.  Wesdnghouse  paid  particular  attention  to  all  aspects  of  the 
design  to  make  the  model  reflective  of  the  concurrent  engineering  process.  As  a  result,  the  model 
contains  all  design  perspectives  and  requirements  for  all  disciplines.  The  product  model  is 
highlighted  primarily  by  the  requirements,  which  includes  the  primary  product  attributes  of  MIL- 
STD-490A.  These  attributes  were  divided  into  a  number  of  sub-attributes,  which  are  not  shown  in 
this  figure.  Appendix  A  contains  the  complete  product  model  with  a  listing  of  the  data  file  used  for 
placement  of  the  model  into  the  PCB. 

The  product  model  as  loaded  into  the  PCB  was  very  comprehensive  but  hard  to  follow  due  to  its 
complexity.  The  presentation  in  the  PCB  needed  to  be  simplified  so  the  users  could  view  a  top- 
level  hierarchy  and  then  selectively  view  the  details  of  sections  of  individual  interest  The  current 
presentation  requires  the  user  to  scroll  through  screen  after  screen  of  material  to  find  the  sections  of 
individual  interest.  In  order  to  provide  product  data  in  an  effective  and  efficient  manner,  the 
product  model  needs  to  be  actively  linked  to  requirements  data,  drawings  and  part  specifications, 
and  other  specific  product  data  required  by  the  individual  disciplines  to  perform  their  required 
tasks.  Without  these  linkages,  the  task  of  manually  inputting  the  required  data  would  be  very  time 
consuming  and  diminish  the  benefit  to  the  product  design  process. 


Figure  9.  SPX-32  Overall  Product  Model  Structure. 
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332  Process  Model  and  Design  Disciplines 

In  a  general  sense,  a  process  model  is  a  description  of  the  activities  and  other  pertinent  information 
about  these  activities  required  to  develop  a  class  of  product  For  the  pilot  project  design, 
Wesdnghouse  developed  a  process  model  for  performing  a  subset  of  activities  done  during  Full 
Scale  Development  for  a  signal  processor  module.  The  process  model  for  the  pilot  project  design 
was  developed  based  on  the  Westinghouse  Integrated  Product  Development  Team  (IPDT)  guide 
[5]  that  has  recently  been  developed  by  a  process  action  team  under  Westinghouse’ s  Total  Quality 
Management  program.  The  IPDT  guide  was  approved  by  Westinghouse  management  at  the 
Division  General  Manager  level,  and  is  in  use  on  projects  such  as  the  F-22  radar. 

The  IPDT  guide  provides  a  reference  for  the  product  development  team  leader  as  the  team 
progresses  through  the  various  phases  of  a  design.  It  is  based  cm  a  multi-discipline  approach  that 
defines  the  functions  of  each  team  member  and  their  activities  and  the  specific  outputs  that  the  team 
members  are  responsible  for  in  each  phase.  It  also  provides  the  team  leader  with  a  check  list  to 
help  focus  cm  the  cone  functional  outputs  necessary  to  execute  a  successful  program. 

Based  on  the  IPDT  guide,  the  scope  of  the  pilot  project  was  selected.  The  first  aspect  was  to  select 
the  appropriate  phase  of  the  product  development  cycle  for  gaining  maximum  information  on  the 
application  of  the  DICE  tools.  The  various  phases  of  military  products  are  shown  in  Figure  10, 
and  include  concept  exploration,  demonstration  and  validation,  full  scale  development,  production, 
and  operations. 

Early  in  the  concept  development  phases,  many  decisions  are  made  affecting  product  cost,  and 
typically  by  the  middle  of  the  Full  Scale  Development  (FSD)  phase,  85%  of  the  decisions 
impacting  die  the  operating  and  support  costs  of  a  product  are  made.  The  cost  savings  potential  of 
concurrent  engineering  in  these  early  phases  comes  about  primarily  as  a  cost  avoidance  due  to 
making  good  tradeoff  decisions.  The  cost  savings  potential  in  later  phases  come  about  due  to 
doing  the  details  of  die  design  without  error. 

It  was  decided  that  the  FSD  phase  would  provide  a  high  payback  region  in  which  to  evaluate  the 
DICE  technology.  The  front  portion  of  the  FSD  phase  was  where  concentration  was  placed  for  the 
pilot  project  tasks,  as  many  of  die  high  impact  tradeoff  decisions  are  made  early  in  this  phase  and 
the  need  for  multidiscipline  team  member  communication  is  the  highest  It  was  also  felt  that  the 
need  and  resulting  benefit  for  new  tools  and  capabilities  was  the  highest  in  this  phase  of  the  design 
process,  as  the  commercial  electronics  CAD  tools  currently  available  concentrate  more  on  the 
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detailed  design  aspect,  instead  of  the  preliminary  design  process  where  many  important  decisions 
are  made. 
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Figure  10.  Military  Product  Phases. 

After  selecting  the  up  front  activities  in  the  full  scale  development  phase  as  the  targeted  portion  of 
the  process,  a  subset  of  disciplines  to  be  involved  in  the  pilot  project  design  was  selected  in  order 
to  keep  the  scope  of  the  project  within  die  cost  and  schedule  constraints  of  Phase  4.  The  design 
disciplines  selected  were  the  ones  with  primary  involvement  during  the  selected  tasks  and  consisted 
of  a  project  lead,  a  systems  engineer,  an  electrical  design  engineer,  a  mechanical  engineer,  a 
producibility  engineer,  and  a  supportability  engineer. 

Detailed  task  planning  for  these  disciplines  was  then  performed.  The  tasks  to  be  performed  by 
each  discipline  were  derived  from  the  IPDT  guide  and  are  shown  in  Table  2.  These  tasks  are  a 
representative  subset  of  the  major  activities  done  in  the  full  scale  development  phase,  and 
concentration  was  made  on  selecting  those  tasks  which  required  multidiscipline  interactions. 
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Table  2.  Pilot  Project  Disciplines  and  Tasks. 


Project  Lead  Tasks 


Develop  Program  Schedules 
Establish  Program  Cost  Reporting  System 
Create  Design  Review  Plan 
Develop  Preliminary  LRM  Family  Tree 
Maintain  Cost  Performance  Tracking 
Maintain  Technical  Performance  Tracking 
Conduct  Internal  Design  Reviews 
Prepare  Weekly  Status  Report 
Conduct  PDR 

Closeout  PDR  Action  Items 
Conduct  Critical  Design  Reviews  (CDR) 
Closeout  CDR  Action  Items 


Tasks 


Review  System  Requirements 

Refine  Functional  Line  Replaceable  Module  (LRM)  Allocations 
Refine  Interface  Requirements 
Update  Family  Tree 
Define  LRM  Interfaces 

Flow  Down  Design  Requirements  To  Component  Assembly 
Develop  Preliminary  LRM  Functional  Design 
Conduct  Preliminary  Design  Review  (PDR) 

Closeout  PDR  Action  Items 
Update  Interface  Control  Document  B2  Specs 
Update  System  Verification  Plan 
Conduct  Critical  Design  Review  (CDR) 

Closeout  CDR  Action  Items 


Tasks 


Refine  Power  Allocations 

Develop  LRM  Design  Concepts  and  Solutions 

Develop  Preliminary  LRM  Electrical  Design 

Develop  Preliminary  LRM  Parts  List 

Define  Printed  Circuit  Board  (PCB)  Layout  Guidelines 

Perform  LRM  Circuit  Partitioning 

Perform  Detailed  Electrical  Design 

Perform  Detailed  Circuit  Analysis 

Prepare  Detailed  Test  Requirements 
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asks 


Refine  Weight  and  Size  Allocations 
Refine  Thermal  Allocation 
Prepare  Drawing  Tree 
Perform  Mechanical  Trade  Studies 
Perform  Thermal  Trade  Studies 
Perform  Preliminary  Mechanical  Design 
Define  Detailed  Mechanical  Design 
Perform  Detailed  Thermal  Analysis 
Release  Final  Drawing  Package 


Tasks 


Generate  Initial  Producibility  Plan 

Evaluate  Production  Strategy 

Evaluate  Procurement  Strategy 

Develop  Manufacturing  Strategy 

Define  Preliminary  Manufacturing  Requirements 

Create  Design  To  Cost  Plan  Goals 

Conduct  Preliminary  Producibility  Analysis 

Evaluate  Detailed  Manufacturing  Technology  Requirements 

Develop/Analyze  Detailed  Manufacturing  Processes 

Assess  New  Manufacturing  Processes 

Develop  Prod  Test  Equipment  (PTE)  Requirements 

Analyze  For  Producibility 

Develop  Detailed  Process  Instructions 

Support  Testability  Design/Analysis 

Determine  Compatibility  With  Current  Capabilities 

Support  Material  Requirements  Planning  (MRP) 

Finalize  Producibility  Plan 


1 


Refine  Reliability  Allocation 
Refine  Testability  Allocations 
Evaluate  Test  Requirements 
Establish  Test  Philosophy 
Identify  Test  devaluation  (T&E)  Options 
Perform  T&E  Trade  Studies 
Develop  LRM  Testability  Approach 
Define  Maintainability  Design  Criteria 
Develop  Reliability  Math  Model 
Perform  Preliminary  Maintainability  Analysis 
Perform  Preliminary  Built  In  Test  Analysis 
Perform  Preliminary  Failure  Analysis 
Cowhict  Maintainability  Trade  Studies 
Conduct  Logistics  Support  Analysis 
Conduct  Life  Cycle  Cost  Analysis 
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The  next  task  involved  identification  of  areas  of  process  improvement  The  high  level  tasks 
performed  in  the  FSD  phase  were  reviewed,  and  the  design  team  identified  techniques  that  would 
improve  their  performance  in  these  general  areas.  Several  aspects  were  found  to  be  valuable  in 
multiple  tasks,  such  as  increased  visibility,  multidiscipline  tradeoff  interactions,  and  design  and 
analysis  tool  integration.  These  improvements  are  shown  in  Figure  1 1 . 
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Figure  11.  Process  Improvement  Areas. 


The  next  task  involved  the  mapping  of  die  DICE  technology  to  the  specific  individual  tasks  in  the 
pilot  project  Utilizing  the  general  process  improvements  identified  at  the  higher  task  level,  the 
applicability  of  the  DICE  tools  to  each  of  the  above  process  steps  was  determined.  For  each 
detailed  task  to  be  performed  in  the  pilot  project  the  disciplines  involved  developed  projections  of 
their  anticipated  usage  of  the  various  DICE  tools  based  on  the  previously  performed  unit  tool 
evaluations.  Table  3  shows  this  projected  tool  application  mapping  as  determined  by  die  various 
members  of  the  design  team. 
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Table  3.  Mapping  of  DICE  Tools  Applicability  to  Pilot  Project  Design  Tasks 


Pilot  Project  Task 


Schedules  (Tiered  St  Harmonized) 


Budgets  Allocated/Accepted  _ 


Risk  Management  Plan 


Manufacturing  Plan  _ 


Make/Buy  Plan  Update 


Transition  To  Production  Plan 


Manufacturing  Technology  Capabilities  Assnmt 


Test  Equipment  Approach _  _ 


Assign  Organizational  Responsibilities _ 


EPDT  Reporting/Visibility  System 


Correspondence  Distribution  List 


Customer  Interface  List 


Change  Control  Board/Signature  Authority 


Design  To  Cost  (DTC)  Plans/Goals 


Manufacturing  Operations  Management  Plan 


Configuration  Management  (CM)  Plan 


Integrated  Logistic  Support  Plan  (ILSP)  /Goals 


Reliability  Plan 


Testability  Plan 


Design  Review  Plan  (Internal,  PDR,  CDR) 


Functional  Flow  Block  Diagrams 


System  Specification  Tree 


Power  Budget 


Size  Budget 


Budget 


Cooling  Budget _ 


Reliability  Budget 


Requirements  Allocation  Sheets  (RAS) 


Final  B2  S 


Final  Interface  Requirements  Specs  (IRS) 


Released  Documents 


Maintainability  Design  Criteria _ 


Maintainability  Program  Plan _  _ 


Maintainability  Testing  Allocation  Report  _ 


Reliability/Failure  Rate  Allocation  Report 


Reliability  Math  Model 


Updated  ILS  Plan  _  _ 


LSA  Integrated  Support  Plan  (SP) 


LCCR 


Design  to  LCC  Plan  _ 


DTC  R 


Producibility  Plan  _  _ 


Procurement  Specs,  SCD's,  Envelope  Drawings 


Interface  Control  Dra 


Guidelines 


ICD's 


PDR  Action  Item  List 


Block 


Schematics 


Lead  ]  Sys  j  Elec 


Mech  |  Sppt  I  Applicable  Tools 
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EDN. 
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Preliminary  Pam  List 


Family  Tree 


Preliminary  Individual  Board  Schematics 


Testability  Approach 


Sketches  &  Layouts 


Timing  &  Sizing  Budget  Report 


Preliminary  Thermal  Analyses 


Key  Processes  Requiring  Development  (MPACT) 


Test  Requirements  Specs  (TRS) 


Failure  Rate  Prediction  (Part  Count) 


Built  In  Test  (BIT)  Effectiveness  Report 


Baseline  Maintainability  Report 


Critical  Test  Interfaces 


Test  Points 


Producibility  Analysis  Report  (PAR) 


Updated  Production  Plan 


Producibility  Design  Guidelines  _ 


Producibility  Design  Guidelines 


Producibility  Design  Guidelines 


Manufacturing  Flows  and  Data 


Updated  Specs  &  ICD's 


Design  Compliance  Matrices 


PDR  Completion  Certificate 


CDR  Meeting  Action  Items/Minutes 


CDR  Completion  Certificate 


Updated  Performance  Report 


Cost  Driver  Analysis  Report 


TPM  Report  _ 


Updated  Parts  List _ 


PCB  Layout  Guidelines 


Update  Top-Down  Break-Down _ 


TestS 


Simulation  Analysis  Report _ 


Design  Approval/Updates  _ 


Thermal  Report _ 


Drawing  Tree 


Drawings  or  Digital  Data 


Test  Requirements  Cross  Reference  Index  (TRCRI) 


Production  Plan  Update 


Producibility  Plan  Update 


Production  Plan  Update 


Production  Plan  U 


Detailed  Process  Flow 


Detailed  Process  Instructions 


Master  Production  Schedule  Report 


Failure  Rate  Prediction  Report  (Part  Stress) 


Built  hi  Test  Effectiveness 


Maintainability  Predictions 


EDN,  KS 


EDN.PCB 


EDN,  MONET 


EDN,  PCB 


EDN,  PCB 


EDN.PCB 


EDN.PCB 


Plan 


Preliminary  Mechanical  Sketches 
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After  the  project  was  defined  in  detail,  a  program  plan  was  developed  in  the  Mac  Project 
commercial  scheduler  program  that  identified  tasks,  durations,  start  and  end  dates,  dependencies 
and  project  critical  paths.  The  MacProject’s  dependency  and  project  tables  were  then  translated 
into  a  LASER  data  base  compatible  format  file  (LASER.OBJ)  using  a  translator  utility  provided  by 
CERC.  The  translated  LASER_OBJ  file  was  then  used  by  the  PCB  for  the  project  task  structure. 
The  MacProject  network  chart  as  well  as  the  corresponding  translated  LASER_OBJ  file  are  shown 
in  Appendix  B.  Once  the  PCB  task  structure  was  established,  the  PCB  was  used  by  the  project 
lead  and  die  design  team  to  access  the  project  task  network. 

3.3.3  Metrics  Selection 

Metrics  were  an  important  part  of  the  pilot  project,  as  they  provided  the  objective  assessment 
mechanism  by  which  the  impact  of  the  DICE  technology  was  determined.  As  part  of  the  pilot 
project  planning  process,  Westinghouse  went  through  a  selection  process  to  determine  the  most 
appropriate  metrics  to  be  collected  during  the  pilot  project  design.  A  process  called  Concept 
Selection  was  used.  Concept  Selection  is  similar  to  the  Quality  Function  Deployment  (QFD) 
process,  in  which  product  requirements  from  various  customers  are  used  to  determine  design  and 
production  goals  for  meeting  the  requirements.  In  concept  selection,  various  concepts  are 
evaluated  against  the  requirements  and  then  against  each  other  for  selection  of  the  best  concepts  to 
use.  In  this  case,  candidate  metrics  were  evaluated  against  the  customer  requirements  for  the 
assessment  of  DICE  tool  impact,  and  also  against  criteria  for  "good"  metrics  to  arrive  at  a  list  of  the 
best  metrics  to  be  used  in  the  project. 

The  first  step  in  the  concept  selection  process  was  to  define  the  customers  for  the  metrics.  The 
customers  were  defined  as  DARPA,  CERC,  the  end  users  of  the  tools,  and  the  managers  of  the 
end  users.  Brainstorming  sessions  were  used  where  the  requirements  of  the  customers  were 
brought  out  The  following  is  a  list  of  the  perceived  customer  requirements  of  tire  metrics  which 
were  derived  in  the  process: 

•  Have  the  DICE  tools  helped  enable  Concurrent  Engineering? 

•  How  have  the  tools  helped  (Qualitatively)? 

•  How  much  have  the  tools  helped  (Quantitatively)? 

•  How  can  the  tools  be  improved? 

•  What  is  tire  cost  of  implementation  ($)? 

•  Are  the  tools  easy  to  use? 

•  Are  the  tools  worth  getting? 

•  What  is  the  cost  of  use  (Time)? 

•  Are  the  tools  usable  with  a  minimal  cultural  change? 
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The  metrics  selection  group  not  only  wanted  to  choose  metrics  which  satisfied  the  customer 
requirements  on  DICE  impact,  but  they  also  wanted  to  ensure  that  the  metrics  chosen  met  the 
criteria  for  good  metrics.  The  following  list  contains  the  criteria  which  were  developed  and  used 
for  evaluating  the  "goodness"  of  the  metrics  analyzed: 

•  Is  there  a  baseline  for  comparison? 

•  Can  a  collection  method  be  defined? 

•  Can  the  metric  be  accurately  measured? 

•  Is  the  metric  repeatable? 

•  Is  die  metric  quantifiable? 

•  Is  the  metric  supportable? 

•  Is  there  a  simple,  easy  method  to  collect  the  metric? 

•  Is  the  metric  responsive  to  known  changes? 

Importance  ratings  for  the  customer  requirements  and  good  metric  criteria  were  the  next  step  in  the 
concept  selection.  Since  DARPA  and  CERC  were  the  main  customers  for  the  results  of  the  tool 
study,  their  importance  ratings  were  increased  to  1.5  times  that  of  the  end  users  and  end  user 
management  ratings. 

Following  the  determination  of  evaluation  criteria  and  importance  rating  assignments,  sessions 
were  held  to  develop  a  list  of  the  candidate  metrics.  For  each  metric  selected,  an  appropriate 
measurement  unit  was  noted.  This  process  not  only  helped  to  define  the  metrics  further,  but  also 
enabled  the  group  to  delete  some  metrics  which  were  unmeasurable  and,  therefore,  would  not  give 
any  indication  of  the  merit  of  each  tool.  The  following  list  contains  the  metrics  and  their  respective 
measurement  units  which  woe  initially  selected  far  evaluation  against  the  metric  requirements: 

•  Design  Cycle  Time  (Elapsed)  -  Days 

•  Design  Environment  Downtime  for  Maintenance  and  Support  -  Minutes 

•  Design  Task  Rework  Time  Due  to  System  Failures  •  Minutes 

•  Design  Task  Actual  Applied  Time -Hours 

•  Documentation  Time  -  Hours 

•  Tool  Training  Time -Hours 

•  Tool  Overhead  Time  -  Seconds 

•  Tool  Log-on  Time  -  Seconds 

•  System  Performance  (Response  Time) -Seconds 

•  System  Crashes  -  Number,  Cause,  Downtime 

•  System  Support  Cost-  Internal  (Hours),  External  ($) 

•  Design  Change  Requests  (CR)  -  Number  of  CR’s 

•  Evaluation  of  Design  Attributes  vs.  Requirements  -  Percentage 

•  Figure  of  Merit  -  Absolute  Number 

•  Tori  Learning  Curve -Percentage 
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The  next  task  was  to  assess  how  well  each  metric  met  the  requirements  by  developing  a  concept 
selection  matrix.  Each  metric  was  evaluated  against  the  requirements  separately.  The  relationships 
were  noted  as  either  strong,  medium,  weak,  or  none,  and  the  appropriate  symbol  was  placed  in  the 
intersecting  square.  Each  symbol  was  given  a  different  weighting,  with  a  strong  relationship 
weighted  as  9,  medium  as  3,  and  weak  as  1.  The  relative  importance  was  calculated  by 
multiplying  the  average  importance  by  the  relationship  weighting  and  adding  it  to  the  remaining 
products  in  the  respective  column.  The  total  number  for  the  column,  representing  the  absolute 
importance,  was  divided  by  the  sum  of  all  the  columns  to  arrive  at  a  relative  importance  percentage. 

The  completed  Concept  Selection  chart  is  shown  in  Figure  12.  This  chart  was  developed  by 
consensus  over  a  number  of  rating  sessions,  and  provides  an  easy  to  analyze  presentation  of  the 
entire  set  of  concept  selection  ratings.  A  commercially  available  tool  was  used  for  chart  creation 
and  ratings  calculation. 

In  analyzing  the  chart,  it  appeared  that  the  results  were  skewed  towards  the  criteria  of  what  made  a 
good  metric.  In  order  to  analyze  the  metrics  better,  the  single  chart  was  divided  into  two,  with  one 
being  the  metrics  versus  customer  requirements  and  the  other  being  the  metrics  versus  what  makes 
a  good  metric. 

The  results  shown  in  both  charts  were  then  analyzed  in  order  to  determine  a  list  of  metrics  which 
would  meet  the  customer  requirements  and  also  meet  the  criteria  for  good  metrics.  The  metrics 
selection  team  decided  it  would  be  best  to  consider  the  customer  requirements  as  a  higher  priority 
than  meeting  the  good  metric  criteria.  A  chart  was  then  made  ranking  the  metrics  in  descending 
order  according  to  their  relative  importance  as  shown  in  Table  4. 

The  metrics  finally  selected  as  good  candidates  for  the  pilot  project  design  activitiy  were  the 
following: 

•  Evaluation  of  Design  Attributes  vs.  Requirements 

•  Design  Environment  Downtime  for  Maintenance  and  Support 

•  Rework  Time  due  to  System  Failures 

•  Design  Change  Requests  (CRs) 

•  Design  Task  Actual  Applied  Time 

•  System  Crashes 

•  Design  Cycle  Time  (Elapsed  Time) 
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Figure  12.  Metrics  Concept  Selection  Chart 


Page  45 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report 


Table  4.  Metrics  Rating  Chart 


Metric 

Overall  Rating 

Customer 

Good  Metric 

Composite 

(%) 

Requirements^) 

Rating  (%) 

Design  vs  Reqmt 

1 

12 

6 

72 

Downtime 

7 

9 

6 

54 

Rework  lime 

7 

9 

6 

54 

8 

8 

8 

64 

KHSSEBB 

8 

7 

8 

56 

Tool  Overhead 

2 

6 

1 

6 

Figure  of  Merit 

6 

6 

5 

30 

Documentation 

7 

6 

6 

36 

Training 

6 

5 

6 

30 

5 

5 

9 

45 

4 

5 

3 

15 

BHS39 

6 

4 

6 

24 

iMMMlI 

5 

4 

5 

20 

BSSESB 

8 

3 

10 

30 

■BBS* 

5 

2 

6 

12 

The  first  five  metrics  in  the  list  were  chosen  due  to  their  high  relative  importance  to  the  customer 
requirements  as  well  as  their  fairly  high  relative  ranking  in  the  good  metric  criteria.  In  order  to 
chose  whether  or  not  the  remaining  metrics  should  be  used,  a  composite  number  was  created  by 
multiplying  both  relative  importance  numbers  together  from  the  customer  requirements  and  good 
metric  criteria.  The  cut-off  point  for  keeping  the  metric  was  a  composite  of  30  or  above,  as  a 
natural  breakpoint  appeared  to  occur  here.  The  remaining  metrics  which  met  this  criteria  included 
the  last  two  in  the  list  above  along  with  training,  figure  of  merit,  and  documentation.  Training  was 
eventually  cut  from  the  list  due  to  its  lower  relative  importance  in  both  categories,  die  vagueness  of 
actual  training  time  and  the  observation  that  training  would  not  tell  the  team  much  about  the  merit  of 
the  tools.  Figure  of  merit  was  eliminated  later  in  the  pilot  project,  as  it  became  apparent  that  it  was 
measuring  different,  subjective  things  from  person  to  person,  and  thus  was  not  a  good  metric. 
Documentation  time  was  eliminated  as  it  was  felt  it  would  be  captured  with  the  applied  time  metric 
on  tasks  which  involved  documentation. 
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After  this  down  selection  of  the  metrics  was  made,  more  precise  definitions  of  the  metrics  were 
developed  A  pamphlet  published  by  the  Air  Force  Systems  Command  The  Metrics  Handbook 
[6],  provided  the  basic  format  for  these.  These  metrics  definitions  for  the  DICE  pilot  project 
contain  die  following  information: 

•  A  description  of  the  metric. 

•  The  appropriate  desired  action  which  the  metric  is  supposed  to  drive. 

•  The  population  from  which  the  metric  is  drawn. 

•  The  frequency  that  die  measurement  is  taken  and  die  source  of  die  measurement 

•  The  graphic  presentation  that  will  be  used  to  display  die  metric. 

•  The  customers  of  the  metric  who  will  use  the  data. 

•  The  accountable  process  owner  who  is  responsible  for  improving  the  process  that  the  metric 
measures. 

•  The  desired  outcome  of  the  metric  indicating  the  desired  trend  of  the  metric. 

These  definitions  for  each  of  the  metrics  above  were  created  in  detail.  These  definitions  are  given 
in  Appendix  C. 

3.3.4  Pilot  Project  Results 

The  actual  pilot  project  design  activity  took  place  over  a  period  of  approximately  six  months 
(March  through  August,  1992).  In  this  time  frame,  the  design  effort  proceeded  from  the  initial 
requirements  capture  activity  into  the  detailed  design  stages,  with  the  performance  of  approximately 
one  hundred  design  tasks.  During  this  period,  the  design  team  performed  their  design  functions, 
using  the  DICE  tools  where  previously  identified  as  being  applicable.  Two  types  of  data  were 
collected:  the  metrics  data  discussed  in  the  previous  section,  as  well  as  the  users'  perceptions  of 
how  well  the  DICE  technology  was  assisting  them  in  their  job.  The  users’  perceptions  changed 
during  the  course  of  design,  and  in  general,  the  users  felt  that  a  great  deal  of  deficiencies  existed  in 
the  tools.  The  metrics  collected  provide  backup  data  confirming  these  subjective  impressions,  as 
only  a  small  gain  in  productivity  (15-20%)  resulted  in  these  tasks.  The  users  felt  that  the 
technology  had  a  much  larger  potential  (greater  than  50%)  in  improving  the  design  process  if  the 
enhancements  identified  during  the  evaluations  were  incorporated.  The  following  paragraphs 
discuss  the  results  of  the  metrics  which  were  collected,  followed  by  the  individual  usability 
conclusions  from  each  of  die  disciplines  involved  in  the  design. 

3.3.4. 1  Metrics  Results 

The  metrics  collected  can  be  grouped  into  three  classes:  (1)  design  time  metrics,  which  tell  how 
much  more  efficient  the  design  process  is  becoming,  (2)  design  quality  metrics,  which  indicate 
how  much  the  end  product  is  improving,  and  (3)  design  environment  metrics,  which  indicate  the 
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improvement  in  the  evolving  DICE  design  environment  which  was  undergoing  continuous 
enhancement  during  the  pilot  project  design.  A  discussion  of  these  results  follows. 

•  Design  Time  Metrics:  The  design  time  metrics  discussed  in  the  previous  metrics  section  consist 
of  the  applied  time,  which  is  the  actual  time  spent  doing  the  design  tasks;  and  the  elapsed  time, 
which  is  the  calendar  time  from  start  to  finish  from  a  task  or  set  of  tasks.  The  applied  time  can  be 
directly  related  to  cost,  as  an  applied  hour  charged  to  the  design  has  a  certain  costing  rate.  The 
elapsed  time  is  typically  a  function  of  not  only  the  length  of  applied  time  for  each  task,  but  also 
such  factors  as  manloading  resource  availability,  resource  leveling  actions,  and  next  higher  level 
schedule  requirements.  Also,  simply  rearranging  tasks  using  a  critical  path  modeler  can  reduce  the 
elapsed  time  by  eliminating  "dead  time".  On  the  pilot  project,  the  use  of  elapsed  time  as  a  valid 
metric  became  unrealistic  due  to  a  number  of  these  factors.  Some  of  the  factors  included  dead  time 
while  tool  revisions  were  being  installed,  conflicts  with  other  DICE  tasks  such  as  tool  evaluation 
reports,  and  tool  crashes  and  downtime,  which  would  not  be  present  in  a  mature  environment. 
Therefore  the  primary  design  time  metric  for  which  valid  data  was  collected  was  the  applied  time 
metric  for  each  task. 

For  each  member  of  the  team,  daily  applied  time  data  was  collected,  and  a  sample  collection  sheet 
is  shown  in  Appendix  C.  The  overall  conclusions  were  that  a  small  (15-20%)  improvement  in 
design  time  was  achieved,  but  a  much  larger  potential  was  possible.  This  is  exemplified  in  Table 
5,  which  shows  the  set  of  tasks  completed  by  one  of  the  disciplines  (supportability  engineering)  on 
the  pilot  project  The  actual  time  spent  on  each  task  was  compiled  from  the  time  sheets  filled  out 
by  the  designer.  The  standard  times  are  the  times  typically  required  to  perform  die  task.  As  can  be 
seen,  some  tasks  showed  a  reduction  in  time,  and  some  tasks  showed  an  increase  in  time,  due  to 
learning  curves,  unfamiliarity  with  the  tools,  or  other  factors.  The  overall  impact  for  the  entire  set 
of  tasks  for  this  discipline,  however,  was  approximately  a  20%  reduction  in  applied  time  for  the 
design  tasks. 

Realizing  that  many  improvements  had  been  recommended  for  the  DICE  tools  and  were  still  in  the 
process  of  being  implemented,  the  disciplines  were  then  asked  to  project  what  their  applied  time 
would  be  if  the  recommended  improvements  were  incorporated,  based  on  their  DICE  tool 
experiences  to  date.  The  resulting  projection  was  that  a  much  greater  improvement,  around  50%, 
could  most  likely  be  realized  in  the  applied  time  factor.  The  results  were  similar  for  the  other  pilot 
project  disciplines.  The  bottom  line  conclusion  was  that  a  large  potential  for  improvement  still 
existed  in  the  DICE  tools. 
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Table  5.  Applied  Hours  Metric  Analysis-Supportability  Tasks. 


Task 

Actual 

Applied 

Time 

(Hours) 

Typical 

Applied 

Time 

(Hours) 

Time 

Savings 

(Hours) 

Projected  Time 

with  DICE 
Improvements 
(Hours) 

Potential 

Savings  with 
Improvements 
(Hours) 

Potential 

Savings  with 
Improvements 

(%) 

Task  A 

10 

8 

-2 

6 

2 

25 

Task  B 

20 

10 

-10 

8 

2 

20 

Task  C 

19 

10 

-9 

7 

3 

30 

TaskD 

18 

10 

-8 

6 

4 

20 

Task  E 

22 

40 

18 

18 

22 

55 

Task  F 

15 

8 

-7 

7 

1 

12 

TaskG 

19 

8 

-11 

7 

1 

12 

TaskH 

115 

200 

85 

80 

120 

60 

Total 

238 

294 

56 

139 

155 

53 

•  Design  Quality  Metrics:  The  design  quality  metrics  consisted  of  the  evaluation  of  the  design 
attributes  versus  the  requirements  and  the  number  of  change  requests  after  the  design  is  released 
into  the  fabrication  phase.  The  design  attributes  were  intended  to  be  evaluated  against  the 
requirements  on  a  periodic  (such  as  weekly)  basis  using  the  Design  Assessment  Tool  (DAT) 
capability  in  the  PCB.  The  DAT  function,  however,  was  not  completed  in  the  pilot  project 
timeframe  by  the  tool  developers  and  consequently  not  delivered  to  Westinghouse  on  this  phase. 
Since  the  automated  monitoring  of  the  requirements  could  not  be  performed  due  to  the  non¬ 
availability  of  the  software,  and  the  manual  monitoring  of  the  requirements  would  have  involved  an 
extremely  time  consuming  effort,  this  metric  was  deferred  until  the  availability  of  the  DAT 
function. 

The  number  of  change  requests  after  design  release  requires  actual  unit  fabrication  to  provide  an 
accurate  assessment  of  the  design  quality,  so  the  actual  collection  of  this  metric  must  be  collected  in 
a  later  phase,  as  discussed  in  the  metrics  definition  in  Appendix  C.  However,  to  provide  some 
assessment  of  the  design  quality  within  the  pilot  project  duration,  the  number  of  change  requests 
resulting  from  the  Preliminary  Design  Review  (PDR)  can  be  used  to  give  an  indication  of  how 
design  quality  can  be  improved  using  DICE.  A  decrease  in  the  number  of  action  items  requiring  a 
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design  change  compared  to  similar  previous  design  efforts  can  indicate  that  design  problems  are 
being  caught  earlier  in  the  design  phase,  providing  a  more  mature  design  at  each  step  of  the 
development  cycle.  For  the  pilot  project,  only  four  action  items  requiring  design  modification 
resulted  from  the  PDR.  This  is  estimated  to  be  approximately  a  one-third  to  one-half  reduction 
compared  to  similar  complexity  designs. 

♦  Design  Environment  Metrics:  The  design  environment  metrics  provided  an  indication  of  the  trend 
of  the  design  environment  toward  maturity.  The  metrics  obtained  included  the  number  of  system 
crashes,  the  downtime  of  the  system,  and  the  amount  of  time  spent  in  recreating  design  task  data 
after  a  system  crash  if  in-process  data  or  effort  was  lost  during  die  crash.  These  metrics  were 
captured  in  a  log  book,  and  collection  forms  are  shown  in  Appendix  C.  These  metrics  were 
compiled  weekly  and  plotted  as  shown  in  Figures  13, 14,  and  15  to  provide  a  real  time  picture  of 
the  environment  status. 

The  conclusion  drawn  from  these  metrics  was  that,  after  an  initial  high  rate  of  crashes,  downtime, 
and  rework  time,  the  system  maturity  improved  due  to  software  upgrades  being  incorporated. 
Occasional  peaks  in  the  above  factors  still  occurred,  usually  corresponding  to  a  new  software 
version  with  a  recurring  problem.  In  general,  by  the  end  of  pilot  project,  the  environment  was 
relatively  stable  and  most  problem  causing  factors  were  identified.  Although  numerous  bugs  and 
functional  limitations  still  existed,  the  design  team  had  learned  to  avoid  the  operations  which 
caused  system  failures. 


Figure  13.  Design  Environment  "Crash"  Metrics. 
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Figure  14.  Design  Environment  Downtime  Metrics. 


Figure  15.  Design  Environment  Rework  Time  Metrics. 

33.42  Pilot  Project  Design  Team  Perspectives 

The  metrics  described  in  the  preceding  sections  are  representative  of  a  fairly  small  sample  size  and 
cannot  by  themselves  provide  a  bill  picture  of  the  pilot  project  results.  Direct  end  user  feedback  in 
this  early  phase  of  the  DICE  development  provides  an  important  insight  into  the  pilot  project 
results,  as  they  describe  how  the  users  actually  used  the  DICE  technology  for  real  design  tasks. 
This  section  contains  each  individual's  perspectives  on  their  experiences  with  these  tools.  A 
description  of  how  each  discipline  involved  in  the  design  used  the  tools,  as  well  as  additional 
recommendations  for  improvement,  follows: 

•  Lead  Engineer  Many  of  the  lead  engineer’s  activities  involved  project  tracking  functions  as  well 
as  technical  guidance.  The  current  version  of  the  DICE  tools,  specifically  the  PCB,  did  not 
provide  any  meaningful  project  management  capabilities,  in  the  form  of  schedule  and  cost  tracking 
and  report  generation.  Although  the  PCB  is  the  main  DICE  tool  for  project  management  and 
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control,  the  primary  DICE  tool  used  in  performing  the  project  lead  tasks  was  the  Electronic  Design 
Notebook,  mainly  for  documenting  and  disseminating  the  various  program  memos.  The  project 
schedule  and  cost  tracking  had  to  be  mainly  done  through  the  MacProject  scheduler  or  manual  page 
and  line  schedule  review. 

Based  upon  its  design  objectives,  the  primary  DICE  support  for  die  project  lead  functions  should 
be  the  PCB  Task  Functions.  The  tested  version  of  the  PCB,  however,  fell  far  short  of  providing 
the  user  with  any  meaningful  project  management  facility  due  to  the  lack  of  certain  key  functions. 
These  include  time  and  cost  management  functions  that  are  the  very  essence  of  any  project 
management  activity.  There  are  no  capabilities  in  this  version  of  the  PCB  to  manage  and  track  the 
progress  of  the  project  schedule  or  cost  If  the  PCB  is  to  become  a  viable  program  management 
tool,  this  function  will  have  to  be  upgraded  to  incorporate  die  capabilities  that  would  automatically 
and  dynamically  update  the  Work  Order  information.  For  example,  the  start  and  finish  dates 
should  reflect  the  actual  dates  a  task  is  started  or  completed.  Similarly,  it  should  be  aide  to  provide 
interim  status  in  the  form  of  percent  complete,  time  and  cost  constraints,  and  potential  impacts  on 
the  project  of  such  constraints.  Project  cost  information  should  also  be  included  in  the  Work  Order 
with  the  capability  to  assess  allocated  cost  against  the  actual  cost  at  each  task  level,  automatic 
accumulation  of  the  cost  at  various  levels  of  the  Work  Breakdown  Structure,  and  cost  variances  at 
the  project  or  subproject  levels.  These  will  help  the  Project  Lead  to  track  the  progress  of  die  project 
and  conduct  regular  schedule  and  cost  reviews.  Also,  basic  "what  if'  analysis  capabilities  should 
be  provided  which  take  into  account  the  inevitable  schedule  revisions,  and  which  would  allow  the 
user  to  assess  the  alternatives  and  select  the  best  (me  based  on  the  situation  at  hand.  Finally,  there 
should  be  a  comment  field  that  can  be  written  into  by  the  users  at  any  time  to  add  relevant 
comments  about  the  task.  These  would  include  information  such  as  progress  status  of  the  task, 
anticipated  problems,  or  other  pertinent  items.  There  are  several  powerful  project  schedulers 
available  commercially  which  can  provide  all  of  the  above  mentioned  capabilities.  Therefore  the 
quickest  and  least  expensive  approach  to  providing  these  capabilities  in  the  PCB  would  be  to 
interface  one  or  more  of  these  commercial  project  schedulers  with  the  Task  Functions. 

•  System  Engineer  The  system  engineer  performs  a  variety  of  conceptual  tradeoffs  and  analysis 
tasks,  as  well  as  requirements  allocation  and  flowdown.  The  primary  DICE  tools  used  in  the 
system  engineering  tasks  were  PCB  and  EDN  (both  Framemaker  and  Aster*X  versions).  Since 
the  results  of  the  systems  analysis  tasks  were  in  the  form  of  a  report  or  a  spread  sheet,  Aster*X 
EDN  was  found  to  be  more  useful.  The  Framemaker  version  of  the  EDN  was  used  early-on  to 
develop  the  system  B-specification  and  document  the  initial  system  concepts.  The  primary  issue 
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with  this  version  of  the  EDN  was  user  frustration  caused  by  very  slow  system  response  and  a 
complicated  layer  of  windows  and  menu  options. 

The  Aster*X  version  of  the  EDN  faired  much  better.  The  spreadsheet  in  the  Aster*X-EDN  was 
used  to  develop  design  parameters  for  various  implementations  of  the  SPX-32  module.  This 
provided  a  common  workspace  for  documenting  the  design  parameters  that  allowed  the  entire 
design  team  to  refer  to  same  information  and  thus  improved  communication  between  the  team. 

The  PCB  was  used  by  the  system  engineer  primarily  to  input  the  design  parameters  in  the  product 
model.  The  concept  of  the  product  model  was  found  to  be  extremely  useful  to  the  system  engineer 
as  it  provided  a  hierarchical  structure  to  view  the  system  and  subsystems.  The  main  drawback  was 
the  fact  that  there  was  no  capability  to  relate  the  various  design  parameters  with  each  other  (e.g., 
the  dependence  of  module  reliability  on  integrated  circuit  junction  temperature)  and  thus  exercise 
"what  if'  scenarios.  Such  relationships  would  provide  the  capability  to  immediately  know  the 
impact  of  design  changes  in  one  aspect  of  die  design  cm  any  other  aspect 

From  the  system  engineer's  perspective,  the  overall  concept  of  PCB  and  EDN  are  an  excellent  idea 
and  an  essential  component  of  the  concurrent  engineering  environment.  However,  the 
implementation  of  the  tools  need  to  be  improved  both  in  functionality  as  well  as  user  interface. 
Linking  of  the  design  parameters  in  the  product  model  of  the  PCB  with  the  EDN  documents  and 
spreadsheets  is  the  major  improvement  needed,  without  which  die  usability  of  these  tools  is  very 
limited. 

•  Electrical  Engineer  The  electrical  engineer  performs  many  design  tasks  using  high  performance 
commercial  electronics  CAD  tools.  The  DICE  tools  were  used  primarily  as  an  adjunct  for 
communication  and  documentation  functions.  The  principle  tools  used  in  performing  the  electrical 
design  tasks  were  the  PCB  and  both  the  Framemaker  and  Aster*X  versions  of  the  EDN.  The  PCB 
Product  Task  Browser  was  used  by  the  electrical  designer  for  viewing  and  acknowledging  the 
tasks  assigned  by  the  lead  engineer.  Use  of  the  PCB's  Task  Browser  provided  no  additional 
insight  to  the  electrical  designer.  In  fact,  often  times  the  tool  was  more  of  a  hindrance  than  a  help. 
This  is  because  the  presentation  of  die  task  data  offered  little  insight  into  die  dependence  of  each  of 
the  tasks  on  each  other.  It  was  desired  to  know  what  kind  of  output  data  was  generated  from  each 
task  and  to  know  what  was  the  next  task  dependent  on  that  data.  The  Product  Task  screen  did  not 
support  the  display  of  these  types  of  relationships.  It  only  showed  the  view  of  the  individual 
perspective  currently  logged  on;  e.g.,  only  the  electrical  engineer's  tasks  were  displayed  to  the 
electrical  engineer.  There  was  no  view  of  the  related  tasks  from  other  disciplines  presented.  Asa 
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result,  for  the  electrical  engineer,  the  PCB  saved  only  to  view  and  acknowledge  the  individual 
tasks  assigned. 

The  other  part  of  the  PCB,  the  Product  Data  Browser,  was  also  of  little  benefit  to  the  electrical 
designer.  The  Product  Data  Browser  contained  the  product  model  of  the  electronics  module.  The 
presentation  of  the  data  associated  with  the  module  was  overwhelming.  The  model  ottered  into  the 
PCB  represented  only  a  small  portion  of  the  data  found  in  a  large  system,  and  even  with  this  litde 
amount  of  data,  the  PCB  did  not  handle  it  well.  The  presentation  of  the  module  data  was  unwieldy 
because  all  of  the  data  was  presented  at  once  to  the  user  and  could  not  be  partitioned  into  smaller 
views.  It  provided  no  distinction  between  the  types  of  data  presented,  which  made  it  difficult  to 
know  the  level  of  detail  presented.  The  most  serious  shortcoming  of  the  PCB  was  that  it  did  not 
support  the  integration  of  the  product  data  model  into  any  type  of  documentation,  design,  or 
analysis  tools.  It  contained  stand-alone  data  and  required  manual  "checks  and  balances"  to  see  that 
all  of  the  data  was  related.  For  example,  for  the  trade  study  tasks,  a  major  portion  of  the  analysis 
was  done  outside  of  the  DICE  environment  This  was  necessary  because  the  DICE  tools  did  not 
support  electrical  design  tasks  such  as  sizing,  laying  out,  or  partitioning  of  the  elements  involved  in 
a  design.  Once  the  analysis  had  been  done,  it  was  desired  to  have  this  data  entered  automatically 
into  the  Product  Data  Browser.  To  make  the  PCB  useful  to  an  electrical  designer,  it  needs  to  be 
able  to  exchange  data  between  analysis  and  design  capture  tools. 

The  EDN  was  used  primarily  to  document  the  results  of  each  electrical  design  task  and  make  these 
results  available  to  the  DICE  team  of  designers.  Both  versions  of  die  EDN  supported  this  task  to 
some  extent  The  support  really  was  from  the  word  processor  itself  and  not  so  much  from  the 
EDN  software  layered  on  top  of  the  word  processor.  The  EDN  layer  was  often  an  extra  burden 
that  proved  to  be  cumbersome  and  hard  to  use.  The  EDN  stressed  organizing  documents  into  a 
particular  structure.  Emphasis  on  documentation  style  and  organization  is  not  typically  a  priority 
for  a  design  engineer.  Almost  any  commercial  word  processor  on  the  market  today  can  adequately 
support  the  electrical  designer’s  documentation  needs,  and  the  EDN  seemed  to  be  an  overkill.  The 
real  need  was  for  a  tool  that,  once  documentation  was  complete,  could  support  the  designer  in 
partitioning  it  so  that  the  data  values  associated  with  the  documentation  can  be  easily  extracted, 
analyzed,  disseminated,  and  tracked. 

•  Mechanical  Engineer  The  mechanical  engineer's  perspective  on  the  use  of  the  DICE  tools  was 
similar  to  the  electrical  engineer's.  The  primary  tools  used  by  the  mechanical  engineer  were  the 
EDN  and  the  PCB.  The  EDN  was  the  most  useful  tool,  and  was  used  primarily  fen*  making  the 
results  of  the  various  packaging  studies  and  thermal  analyses  available  to  the  team.  The  PCB  was 
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primarily  used  for  reviewing  work  order  data,  as  the  limitations  discused  previously  concerning  the 
product  data  applied  here. 

•  Producibility  Engineer.  The  producibility  engineer's  tasks  include  a  number  of  cost  analyses  and 
producibility  reports.  The  main  tools  used  in  the  completion  of  the  producibility  tasks  were  the 
Aster*X  EDN  and  PCB.  Since  the  thrust  of  the  producibility  tasks  often  were  in  the  form  of  a 
report  or  a  spreadsheet,  Aster*X  EDN  was  used  for  these.  PCB  was  used  primarily  to  obtain  task 
assignments  from  the  project  lead.  Comments  on  tool  shortcomings  are  similar  to  the  previously 
discussed  disciplines. 

•  Supportability  Engineer.  The  supportability  engineer’s  tasks  require  many  inputs  from  the  other 
disciplines  in  order  to  perform  the  many  required  analyses.  The  principal  tools  used  in  the 
performance  of  the  supportability  design  tasks  were  the  PCB  and  EDN,  both  Framemaker  and 
Aster*X  versions.  The  PCB  was  used  by  the  supportability  engineer  to  develop  the  product 
structure,  including  all  design  variables,  receive  task  assignments  from  the  project  lead,  and  to 
acknowledge  their  receipt  as  well  as  their  completion.  The  EDN  was  used  to  develop  and  file  the 
reports  and  memorandums  associated  with  die  supportability  design  tasks.  Again,  it  was 
concluded  that  the  EDN  functions  that  were  developed  on  top  of  these  word  processing  packages 
often  made  them  more  difficult  to  learn  and  use.  The  word  processors  themselves  were  very 
flexible  when  used  without  EDN,  but  became  very  inflexible  when  EDN  was  added. 

Data  collection  for  all  the  supportability  functions,  including  reliability,  maintainability,  safety, 
human  factors,  and  logistics,  is  a  very  time  consuming  and  labor  intensive  activity.  This  is 
especially  true  on  large  programs  involving  an  entire  system  or  on  subsystems  such  as  a  fire 
control  radar.  In  these  larger  projects,  there  is  potential  for  duplication  of  effort  because  of  a 
matrix  organization  and  die  large  number  of  people  involved.  Data  is  collected  from  many  sources 
in  order  for  a  supportability  engineer  to  perform  his  required  tasks,  and  the  data  is  seldom  in  the 
required  format  and  usually  requires  additional  effort  to  manipulate.  For  example,  Westinghouse 
performed  a  reliability  analysis  on  several  options  of  the  SPM  for  the  pilot  project,  which  required 
temperature  data  for  all  the  parts  on  the  module.  In  addition,  many  discrete  parts  such  as  resistors 
and  capacitors  required  an  effort  to  compile  such  data  as  wattage,  voltage  rating,  etc.  in  order  to 
compute  the  failure  rare.  This  data  does  not  usually  appear  on  the  parts  list  and  requires  research  of 
the  individual  parts  drawings  or  MS  specifications,  which  required  the  supportability  engineer  to 
perform  additional  data  gathering.  These  kinds  of  efforts  make  data  collection  for  the 
supportability  functions  a  very  time  consuming  and  labor  intensive  activity.  In  order  for 
concurrent  engineering  technology  is  to  be  useful  and  effective,  the  software  tools  must  be  linked 
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to  the  appropriate  data  repositories  so  the  supportability  engineer  has  electronic  access  to  the 
required  data. 

•  Summary  of  Design  Perspectives:  Based  on  the  individual  disciplines'  experiences  with  the  tools 
on  the  pilot  project,  the  value  of  the  tested  DICE  tools  in  enhancing  concurrent  engineering  varied 
directly  with  the  amount  of  communication  typically  required  for  each  task.  Tasks  which  are 
primarily  communication  oriented,  such  as  allocating  requirements  or  collecting  design  attribute 
data  to  use  in  cross-disciplined  analysis,  were  somewhat  facilitated  by  the  DICE  tools  which  were 
evaluated,  although  a  great  deal  of  enhancement  is  still  required.  Tasks  which  were 
computationally  intensive,  such  as  certain  phases  of  electrical  design,  were  not  impacted  much  by 
DICE  due  to  lack  of  electronic  data  sharing.  In  each  instance,  however,  the  recommendations 
associated  with  the  individual  design  perspectives  relative  to  PCB,  EDN,  and  MONET  are  based 
upon  simplicity,  flexibility,  and  functional  improvement. 
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4.0  CONCLUSIONS 


Both  the  pilot  project  design  experience  and  the  individual  tool  evaluations  provided  data  for 
development  of  conclusions  on  the  degree  of  success  to  which  DICE  technology  enables  computer- 
based  concurrent  engineering.  One  conclusion  is  that  the  high  level  concepts  which  form  the  core 
of  DICE  (coordinating  the  team,  corporate  history,  networked  collocation,  information  sharing, 
and  integrating  tools  and  services)  are  excellent  and  should  contribute  greatly  to  the  concurrent 
engineering  process.  The  other  conclusion  is  that  the  specific  implementations  of  the  technology 
evaluated  in  this  pilot  project  failed  to  live  up  to  the  expectations  for  actually  providing  the 
anticipated  benefits.  Although  the  pilot  project  metrics  showed  a  IS  to  20%  improvement  over 
standard  values  in  the  development  process,  this  was  not  the  large  improvement  desired.  Also,  it 
became  apparent  that  it  is  difficult  to  separate  the  effects  of  the  DICE  technology  from  the  effects  of 
the  natural  team  building  effect  that  occurs  within  a  concurrent  engineering  team.  Some  team 
members  felt  that  the  team  effect  was  the  primary  positive  influence  on  the  design  process,  and  that 
the  benefit  from  the  technology,  due  to  the  problems  experienced  with  these  specific 
implementations,  was  minimal.  However,  there  was  no  accurate,  quantitative  way  to  separate 
these  effects.  The  design  team  felt,  however,  that  a  much  larger  overall  potential  for  improvement 
(over  50%)  existed,  and  developed  technology  improvement  strategies  and  provided  specific 
recommendations  for  obtaining  this  improvement. 

The  primary  deficiency  in  the  DICE  technology  was  that  the  software  was  not  sufficiently  mature 
for  use  in  a  pilot  project.  The  specific  primary  areas  of  deficiency  are  limited  tool  functionality, 
inefficient  user  interfaces,  lack  of  integration,  and  low  reliability.  These  points  are  summarized  as 
follows: 

•  Limited  tool  functions:  Many  of  the  tool  functions  appeared  to  be  derived  from  a  software 
developer’s  perspective  of  what  product  designers  need  to  more  efficiently  perform  their  job, 
as  opposed  to  an  organized  set  of  detailed  requirements  derived  from  the  end  users 
themselves.  As  a  result,  many  of  the  real  time  and  cost  saving  functions  desired  by  the  end 
users  were  not  addressed,  and  some  of  the  functions  which  were  implemented  in  the 
software  were  not  perceived  by  the  end  users  as  being  particularly  important  in  assisting  in 
their  job  functions. 

•  Inefficient  user  interface:  There  was  a  wide  variety  of  types  and  quality  of  user  interfaces 
used  on  this  mix  of  DICE  software.  In  general,  many  of  the  interfaces  had  deficiencies 


Page  57 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report 


which  quickly  degraded  the  impact  of  the  tools.  None  of  the  user  interfaces  was  of  a  quality 
similar  to  typical  commercial  packages. 

•  Lack  of  integration:  A  major  element  of  computer-assisted  concurrent  engineering  is 
electronically  sharing  data,  and  a  major  element  of  electronically  sharing  data  is  the 
integration  of  DICE  tools  with  themselves  as  well  as  with  the  rest  of  the  design  environment 
Most  of  the  technology  evaluated  had  limitations  in  sharing  and  exchanging  data.  Higher 
levels  of  integration  between  tools  are  required  in  subsequent  enhancements  to  these  tools. 

•  Low  reliability:  The  reliability  of  the  versions  of  die  DICE  tools  evaluated  in  this  phase  is  in 
great  need  of  improvement  The  reliability  of  the  individual  tools  was  lowered  even  further 
when  multiple  tools  were  active  on  a  user's  terminal  simultaneously. 

In  summary,  the  DICE  technology  evaluated  on  this  pilot  project  has  shown  potential  for 
improving  the  electronics  development  process.  However,  additional  effort  is  required  to  reach  the 
full  benefit  of  computer  assisted  concurrent  engineering.  A  concurrent  engineering  approach 
applied  to  the  DICE  technology  development  process  itself,  involving  a  team  of  end  users  and 
system  support  personnel  in  addition  to  the  DICE  software  developers,  will  speed  the  attainment  of 
these  benefits.  Specifics  of  these  recommendations  are  provided  in  Section  S. 
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5.0  RECOMMENDATIONS 


The  benefits  of  employing  concurrent  engineering  in  the  product  development  process  have  been 
well  recognized  for  many  years.  Many  successful  projects  have  been  run  in  a  CE  fashion  with 
reduced  development  time  and  cost  and  improved  quality,  and  have  been  implemented  simply  with 
process  changes  without  advanced  technology.  The  objective  of  DICE  has  been  not  to  get 
organizations  to  change  their  culture,  but  instead  to  provide  technology  to  enhance  the  CE  process 
in  organizations  already  implementing  CE.  Based  on  the  conclusions  drawn  in  the  previous 
section,  there  is  still  a  large  potential  improvement  in  developing  computer-based  concurrent 
engineering  technology  yet  to  be  realized.  While  this  potential  is  gradually  being  achieved  through 
ongoing  efforts  such  as  DICE  and  in  new  products  by  commercial  software  developers,  there  is  a 
benefit  in  accelerating  the  maturation  of  this  technology.  As  part  of  this  project,  Westinghouse 
provided  many  recommendations  on  improvements  for  the  DICE  software.  Many  times,  these 
improvements  were  difficult  for  the  developers  to  incorporate  into  the  existing  software  due  to 
implementation  decisions  previously  made  which  prevented  the  improvements  from  being  made 
without  major  revision  to  the  code.  Another  observation  from  the  pilot  project  was  that  the 
availability  and  maturity  of  commercial  software  providing  certain  DICE  type  functions  was 
increasing  and  it  would  be  advantageous  to  leverage  these  commercial  investments  into  the  DICE 
environment. 

The  approach  used  for  the  previous  phases  of  DICE  is  referred  to  as  a  rapid  prototype  development 
approach,  which  is  often  used  when  requirements  for  a  product  are  not  fully  defined.  The 
objective  of  this  procedure  is  to  provide  customers  with  a  prototype  product  quickly,  which  is  then 
used  as  a  vehicle  for  creating  product  responses  and  gathering  requirements  from  the  customers. 
This  new  input  is  then  used  to  develop  a  new  rapid  prototype  version  of  the  product,  and  the  cycle 
is  repeated  until  the  requirements  are  finalized  and  the  product  is  finished.  The  problem 
experienced  with  this  procedure  on  DICE  is  that  the  cycles  are  too  long  (approximately  one  year 
between  major  revisions)  and  the  software  is  not  easily  modified  to  incrementally  incorporate 
desired  improvements.  However,  enough  experience  has  been  gained  on  DICE  that  an  initial 
requirements  specification  can  now  be  created,  allowing  a  more  structured  approach  to  be  used  for 
development.  Also,  techniques  now  exist  allowing  critical  portions  of  the  requirements  to  be 
validated  to  be  cost  effective,  without  the  time  and  dollar  expense  of  developing  fully  coded 
software  prototypes,  by  using  quickly  developed  Graphical  User  Interface  (GUI)  mockups. 
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To  achieve  this,  Westinghouse  recommends  that  a  different  approach  be  used  on  future  DICE 
developments  for  improving  the  Phase  4  concurrent  engineering  technology.  The  key  features  of 
such  an  approach  are: 

•  Use  a  structured  development  process  incorporating  detailed  functional  requirements  to  better 
meet  the  end  users'  needs. 

•  Apply  concurrent  engineering  practices  to  the  development  of  the  DICE  technology  itself  by 
providing  real  time  communications  between  software  developers  and  the  end  user 
community. 

•  Develop  a  "solutions-oriented"  approach  using  the  "best"  implementation,  i.e.,  use  a  proper 
balance  of  new  software  integrated  with  commercial  software  instead  of  creating  all  functions 
from  scratch. 

An  approach  providing  these  features  would  consist  of  generation  of  a  testable  requirements 
specification,  validation  of  this  specification  and  making  appropriate  revisions  to  ensure  that  the 
specification  provides  the  highest  possible  payoff  before  investing  in  its  implementation,  and  then 
implementing  the  software  using  a  structured  software  development  approach. 

The  requirements  specification  should  be  based  on  models  from  systems  and  software 
requirements  specifications,  and  should  address  the  functional  requirements  using  the  high  level 
CE  requirements  espoused  by  DICE  (i.e.,  information  sharing,  integration  of  services,  team 
coordination,  network  collocation,  and  corporate  memory)  as  a  starting  point  From  there,  these 
requirements  should  be  decomposed  in  a  structured  fashion  to  derive  lower  level  requirements  to  a 
very  detailed  level.  The  lowest  level  of  requirements  should  be  the  individual  computer-assisted 
CE  functions  required  by  a  user  and  a  description  of  the  presentation  of  that  function  (user  interface 
screens)  to  the  user.  As  a  result  of  this  detailed  output,  each  one  of  these  low  level  requirements 
could  be  individually  verified  during  software  test,  providing  measurable  milestones  by  which  to 
track  die  software  development  process. 

In  addition  to  this  functional  decomposition,  the  interface  requirements  should  be  defined  up  front. 
These  should  include  specific  database  types  to  be  accessed,  existing  commercial  software  in  use, 
and  network  software  interfacing.  Also,  hardware  constraints  should  be  specified,  providing 
CERC  with  the  experience  in  dealing  with  real  world  constraints  typical  of  those  they  will  work 
with  in  future  customer  relations. 

Early  insight  into  and  feedback  on  this  specification  by  the  DICE  developers  during  the  creation  of 
die  specification  is  a  key  element  of  the  CE  process.  Therefore,  as  the  specification  is  developed,  a 
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computer-assisted  approach  for  capturing  and  tracing  requirements  fen*  the  DICE  software  should 
be  used  Packages  for  requirements  capture  and  flowdown  are  available  commercially,  such  as  the 
RTrace  and  RTS  software  programs.  Use  of  one  of  these  tools  will  provide  the  means  of  making 
the  specification  information  visible  to  the  DICE  developers,  as  well  as  providing  a  configuration 
controlled  history  of  the  requirements. 

The  requirements  specification  developed  in  die  previous  step  would  have  the  benefit  of  experience 
from  the  previous  phases  of  DICE.  However,  validation  of  this  specification,  before  a  sizable 
investment  is  made  in  implementing  it,  is  desirable  to  ensure  that  the  technology  provides  the 
maximum  benefit  to  the  development  process.  As  experienced  on  previous  phases,  features  which 
appear  at  first  to  be  desirable  and  productive  can  often  turn  out  to  not  only  provide  negligible 
benefit,  but  actually  degrade  the  product  development  process  due  to  inappropriately  implemented 
functions  and  interfaces.  To  develop  the  highest  payoff  specification,  the  body  of  knowledge  and 
capability  available  from  the  the  Human-Computer  Interface  community  should  be  applied.  The 
use  of  currently  available  techniques  to  provide  quick  turnaround  graphical  user  interface  mockups 
would  allow  users  to  experience  a  virtual  environment  as  described  in  the  requirements 
specification,  and  allow  necessary  observations  to  be  made  that  the  environment  specification  is 
appropriate.  Contextual  observations  of  users  as  they  perform  their  tasks  per  the  candidate 
specification  should  be  collected.  This  would  provide  the  basis  for  vertically  integrating  the 
evaluation  of  specification  requirements  ranging  from  the  fine  grained  and  perceptual  to  the  broad 
and  cognitive,  and  permit  making  useful  tradeoffs  in  the  user  interface  design  process.  The  end 
result  would  be  a  validated  user  requirements  specification  to  be  used  to  guide  the  remaining  DICE 
developments,  as  well  as  provide  inputs  to  the  Test  Bed  at  CERC  for  implementation  and 
integration  requirements. 

Based  on  the  experiences  of  Phase  4,  a  large  benefit  can  be  realized  by  a  more  formal  development 
process  for  actually  implementing  the  software  itself.  Techniques  from  the  military  standards 
(primarily  Mil-Std  2167),  modified  for  a  commercial  practices  environment,  would  provide  a 
quantum  improvement  in  the  quality  of  the  DICE  software.  Also,  the  concurrent  review  and 
feedback  by  an  end  user  community  of  the  software  developers'  implementation  plans,  software 
development  specifications,  and  other  intermediate  development  documents  should  be  performed. 
In  this  way,  many  issues  causing  potential  problems  down  the  line  can  be  identified  and  corrective 
measures  taken  early.  Some  examples  of  these  problems  from  Phase  4  include  the  undesirable 
hard  coding  of  directory  structures,  improper  termination  procedures  leaving  processes  to 
accumulate  on  the  system,  and  numerous  unnecessary  system  administration  tasks. 
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In  summary,  the  above  recommendations  would  correct  many  of  the  shortcomings  of  the  DICE 
Phase  4  tools  which  were  evaluated  on  this  contract  Westinghouse  recommends  that  the  above 
structured  approach  be  considered  for  any  and  all  enhancements  to  the  DICE  environment 
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Appendix  A.  Product  Model 


This  appendix  contains  data  on  the  electronics  module  product  model  used  in  the  DICE  Project 
Coordination  Board  cm  the  Electronics  Pilot  Project  The  following  information  is  contained: 


1.  Hierarchical  Breakdown  Chart  of  Product  Model  Structure  Page  66 

2.  Listings  for  Electronic  Module  Product  Model  Inputs  to  Project  Coordination  Board  Page  67 


Page  65 


Westinghouse  Electronic  Systems  Group  DICE  Phase  4  Final  Report  Appendix  A 


Page  66 


I 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report  Appendix  A 


Listings  for  Electronic  Module  Product  Model  Inputs  to 
Project  Coordination  Board 

{ 

B_1553 

parts  *  (partof)  :  item_signal 

! 

DFN_bus 

parts  *  (partof) :  item_signal 

I 

IF _perfonnance 

kinds  *  (kindof) :  characteristics 
rate : 

reference : 
size : 
type: 
unit : 

} 

{ 

LRM_mechanical_interface 
kinds  *  (kindof) :  item_mechanical 

} 

{ 

LRM_safety 
parts  *  (partof) :  safety 

! 

LRMjslots 

kinds  *  (kindof) :  item_mechanical 

} 

{ 

LSR  FACET 

CARDINALITY_MAX :  [  Isr_max_cardinality :  ] 

CARDINALITY_MIN :  [  lsr_rxrin_cardinality :  ] 

CHECK_FOR : 

CLASS  :  [  Isr_check_class :  ] 

CLASS_OPTIONS :  "instances" 

ERROR  MESSAGE :  lsr_xecord_facet_errOT 
KEYLIST :  [  lsr_check_keylist :  ] 

PROTECT :  [  lsr_check_protect :  ] 

RANGE :  "LSRJNCLUSIVE"  [  lsr_check_range :  ] 

RANGE.MAX : 

RANGE JV1IN : 

TYPE :  [  lsr_check_type :  ] 

UNIQUE :  [  lsr_check_unique :  ] 

} 

{ 

Pl.bus 

parts  *  (partof)  :  item_signal 
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} 

{ 

TM_bus 

pare  *  (partof) :  item_signal 

} 

{ 

acceptance 

kinds  *  (kindof) :  simplicity_of_design 

} 

{ 

acquisition_cost 

parts  *  (partof) :  equipment_life_cycle_cost 

} 

{ 

allowed_materials 

parts  *  (partof) :  material_processparts_parts 

} 

{ 

assembly 

parts  *  (partof)  :  interchangeability 

} 

{ 

availability_of_materials 
parts  *  (partof) :  producibility_characteri sties 


availability_of_resources 
parts  *  (partof) :  least_time 

} 

{ 

availability_or_labor_skills 
parts  *  (partof) :  manpower 

} 

{ 

available_production_processes 
parts  *  partof) :  high_rate_production 

} 

{ 

average_depot_jepair_time 
parts  *  (partof) :  equipment_life_cycle_cost 

} 

{ 

average_f.eld_repair_time 
parts  *  (partof) :  equipment_life_cycle_cost 

} 

{ 

backplane 

kinds  *  (kindof) :  item_mechanical 

} 

{ 

bending 

parts  *  (partof) :  electrical_grounding_and_bonding 
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} 

{ 

catcgories_of_paits_incl_in_parts_ctrl_pgm 
parts  *  (partof) :  material_processparts_parts 

{ 

character_coo!ing 
kinds  *  (kindof) :  characteristics 
rate : 

reference : 
typel : 
type2: 

} 

{ 

character_physical 
kinds  *  (kindof) :  characteristics 
partof  *  (parts) :  character_physical_cooling 
character_physical_discretes 
character_physical_electrical_power 
character_physical_software 
character_physicaljphysical 
character_physical_signal 

} 

{ 

character_physical_cooIing 
parts  *  (partof) :  character_physical 

I 

character_physical_discretes 
parts  *  (partof) :  character_physical 

! 

character_physical_electrical_power 
parts  *  (partof) :  character  physical 

! 

character_physical_physical 
parts  *  (partof) :  character_phy sical 

I 

character_physical_signal 
parts  *  (partof) :  character_physical 

} 

{ 

character_physical_software 
parts  *  (partof)  :  character_physical 


{ 

characteristics 

kindof  *  (kinds) :  IF_pcrfonnance  character_physical  character_cooling 
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functional  j>erfonnance  maintainability  reliability 
testability 

kinds  *  (kindof) :  requirements_perspective 

} 

{ 

chassis_grounds 
parts  *  (partof) :  grounding 


{ 

checkout 

kinds  *  (kindof) :  simplicity_of_design 

} 

{ 

clarity__of_technical_data_package 
kinds  *  (kindof) :  design_characteristics 
partof*  (parts) :  reliable_concrete_design_infomation 

} 

{ 

clock 

kinds  *  (kindof) :  item_discretes 

} 

{ 

component 

pacts  *  (partof) :  interchangeability 

! 

configurations 

parts  *  (partof)  :  high_rate_production 


conformaLcoatings 

parts  *  (partof) :  material_processparts_parts 

} 

{ 

connectors 

parts  *  (partof) :  material_processparts_parts 

{ 

continental_US_depot_SE 
parts  *  (partof)  :  support_equipment 

} 

{ 

cooling_provisions 
parts  *  (partof) :  item_cooling 

{ 

cooling  source 
parts  *  (partof) :  item_cooling 
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{ 

corroaon_prevention 

parts  *  (partof)  :  materi&Lproce  s  sparts_parts 

1 

dcsign_and_construction 

kindof  *  (kinds) :  electrornagnetic_environmentaI_effects 

design_and_construction_softwarc  workmanship 
interchangeability  material_processparts_parts 
safety  manpower_and_personnel_integratk>n 
kinds  *  (kindof) :  requircrnents_perspective 

} 

{ 

design_and_construction_software 

kinds  *  (kindof) :  design_and_construction 
kindof  *  (kinds) :  programming_languages  design_standards 
software_integration 
software_sizing_and_tiirdng_constraints 

} 

{ 

design_characteristics 

kmdof*  (kinds) :  clarity_of_technical_data_package 
fkxibility_in_pioduction_choices 
tolerance_requirements 
selecdon_ciiteria_for_specified_material  s 
kinds  *  (kindof) :  manufacturings. _producibility_perspective 
partof*  (parts) :  simplicity_ofjdesign 

} 

{ 

design_standards 

kinds  *  (kindof) :  design_and_constmction_software 

} 

{ 

design_for_maintainability 
parts  *  (partof) :  human_factors_engineering 

} 

{ 

design_for_operability 

parts  *  (partof) :  human_factors_engineering 

} 

{ 

dielectric jequirements 
parts  *  (paitof) :  material_processpaits_parts 

I 

dimensions 

parts  *  (partof) :  high_rate_production 

} 

{ 

documentation 

kindof  *  (kinds) :  drawings  electronic_data_files  specs 
technical_manuals 
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kinds  *  Qdndof) :  requircmcnts_perspective 

} 

{ 

documcntadon_perspective 
kinds  *  (kindof) :  module_pcrspectives 

} 

{ 

drawings 

kinds  *  (kindof) :  documentation 

filename: 

location: 

reference: 

spec_NO: 

tool: 

} 

{ 

electric_power 

kinds  *  (kindof)  :  interface_definition 

partof  *  (parts)  :  input_noise_ripple  input_power  input_voltage 

} 

{ 

electncal_discharge_machining 
parts  *  (partof)  :  material_processparts_parts 

} 

{ 

electrical  grounding  and  bonding 
parts  *  (partof) :  material_processparts_parts 
partof  *  (parts)  :  bonding  grounding 

) 

{ 

electrical_or_electronic_parts_vibranon 

parts  *  (partof)  :  material_processparts_parts 

} 

{ 

electriealjsafety 
parts  *  (partof) :  safety 

{ 

dectromagnetic_environmental_effects 
kinds  *  (kindof)  :  design_and_construction 
kindof  *  (kinds) :  hazards_of_electromagnetic_radiation_to 

} 

{ 

electromc_data_files 
kinds  *  (kindof) :  documentation 
description : 
file.name : 
reference : 
tool: 

} 

{ 

electrostatic_discharge_sensitive 
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parts  *  (partof)  :  material_processparts_parts 

} 

{ 

equipment_life_cycle_cost 

partof  *  (parts) :  acquisition_cost  average_field_repair_time 
average_depot_repair_time  spares_cost 

} 

{ 

equipment_personnel 
reference : 
skill Jevel : 

) 

{ 

equipmentjraining 
course_length : 
reference: 
type: 

} 

{ 

estimated_annual_operating_hours 
parts  *  (partof) :  spares 

( 

estinaated_technical_manual_cost 
parts  *  (partof) :  spares 

} 

{ 

estimated_test_equipment_cost 
parts  *  (partof) :  spares 

I 

estimated_training_cost 
parts  *  (partof) :  spares 

I 

fabrication 

kinds  *  (kindof) :  simplidty_of_design 

} 

{ 

facilities 

partof  *  (parts) :  production_capabilities 
parts  *  (partof) :  producibility_characteri sties 

I 

facilities_and_facility_equipment 
kinds  *  (kindof) :  logistics 
name: 
reference: 


{ 

finishes 
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parts  *  (partof) :  material_processparts_parts 

{ 

flcxibility_in_production_choices 
kinds  *  (kindof) :  design_characteristics 
partof*  (parts) :  identify_altemate_materials_and_processes 


forgings 

parts  *  (partof)  :  material_processparts_parts 

} 

{ 

function_definition 

kinds  *  (kindof) :  item_definition 

} 

{ 

functional_performance 
kinds  *  (kindof) :  characteristics 
ICD : 

bandwidth: 
rate : 

reference : 
size : 
type: 
unit: 

} 

{ 

grounding 

parts  *  (partof) :  electrical_grounding_and_bonding 
partof  *  (parts) :  chassis  grounds 


{ 

hazards_of_electromagnetic_radiati<xi_to 
kinds  *  (kindof) :  electromagnetic_environmental  effects 

} 

{ 

health_hazards 

parts  *  (partof) :  safety_personnel 


{ 

heat_dissipatkm 
parts  *  (partof) :  item_cooling 


{ 

high_rate_production 

partof  *  (parts) :  dimensions  configurations 

available_production jnocesses  tolerances 
parts  *  (partof) :  production_or_inspection_required 
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) 

{ 

human_factors_engineerin  g 

paitof  *  (parts) :  design_for_main  taxability  design  Jbr_operability 
parts  *  (partof) :  manpower_and_personnel_integration 

} 

{ 

identify_Min_quality_levels_required_to_meet 
parts  *  (paitof) :  tolerance_requirements 

} 

{ 

identify_altemate_materia1s_and_proc  esses 
parts  *  (partof) :  flexibility_in_production_choices 

} 

{ 

in_theater_depot_SE 
parts  *  (partof)  :  support_equipment 

} 

{ 

input_noise_ripple 
parts  *  (partof)  :  electric_power 

} 

( 

input_power 

parts  *  (partof)  :  electric_power 


{ 

input_voltage 

parts  *  (partof) :  electric_power 

) 

{ 

inspection 

kinds  *  (kindof) :  siraplicity_of_design 

} 

( 

installation 

kinds  *  (kindof) :  simplicity_of_design 

} 

{ 

insolation jresistance 

parts  *  (partof) :  material_piocessparts_parts 

} 
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{ 

interchangeability 

kinds  *  (lrindof)  :  design_and_construction 
partof  *  (parts) :  assembly  component  parts 

} 

{ 

interface_definition 

kindof  *  (kinds) :  electric_power  item_discretes  item_physical 
item_signal  item_software  item_cooling 
kinds  *  (kindof) :  item_definition 

} 

{ 

item_cooling 

kinds  *  (kindof)  :  interface_definition 

partof  *  (parts) :  heat_dissipation  cooling_source  cooling_provisions 

) 

{ 

item_definition 

kindof  *  (kinds) :  interface_definition  function_definition 
kinds  *  (kindof) :  requirements j)erspective 

} 

{ 

item_discretes 

kindof  *  (kinds) :  clock  reset 
kinds  *  (kindof) :  interface_definition 

} 

{ 

item_electrical 

kindof*  (kinds) :  item_electrical_electrical  optical 
kinds  *  (kindof) :  item_physical 

} 

{ 

item_electrical_electrical 
kinds  *  (kindof) :  item_electrical 

} 

{ 

item_mechanical 

kindof*  (kinds) :  LRM_mechanical_interface  backplane  LRM_slots 
kinds  *  (kindof) :  item_physical 

} 

{ 

item_physical 

kindof*  (kinds) :  item_electrical  item_mechanical 
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kinds  *  (kindof) :  interface_definition 

} 

{ 

item_signal 

kinds  *  (kindof) :  interface_definition 

paitof  *  (parts) :  B_1553  TM_bus  PI_bus  DFN_bus 


{ 

item_software 

kinds  *  (kindof)  :  interface_definition 

} 

{ 

junction_temperature 
parts  *  (paitof)  :  thermal_design 

} 

( 

least_cost 

kinds  *  (kindof) :  optimal_cost_or_tiine 

partof  *  (parts) :  simplicity_and_standard_in_comps_and_manuf_procs 

{ 

least_time 

kinds  *  (kindof) :  optimaI_cost_or_tiine 
partof*  (parts) :  availability_of_resources 


{ 

logistics 

kindof*  (kinds) :  facilities_and_facility_equipment  maintenance  supply 
support_equipment 

kinds  *  (kindof) :  requirements_perspective 


{ 

low_rate_production 

parts  *  (partof) :  production_or_inspection_required 


{ 

maintainability 

kinds  *  (kindof) :  characteristics 

maintenance_level : 

parameter: 

reference: 

unit: 

value: 

} 
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{ 

maintenance 

kinds  *  (kindof) :  logistics 
concept : 

maintenance_skill_level : 
reference : 

} 

{ 

manpower 

partof  *  (parts) :  availability_or_labor_skills 
parts  *  (partof) :  producibiHty_characteri sties 


{ 

manpower_and_personnel_integration 

kinds  *  (kindof)  :  design_and_construction 

partof*  (parts) :  human_factors_engineering  manpower_or_personnel 
manpowerjraining  system_safety_or_health_hazards 


{ 

manpower_or_personnel 

parts  *  (partof) :  manpower_and_personnel_integration 


{ 

manpower_training 

parts  *  (partof)  :  manpower_and_personnel_integration 

} 

{ 

manufacturxng_or_producibility_perspecnve 
kindof*  (kinds) :  design_characteristics  optimal_cost_or_time 
producibifity_characteristics 
production_or_inspection_required 
kinds  *  (kindof) :  module_perspectives 


{ 

material_processparts_parts 
kindof*  (kinds) :  parts_selection_criteria 
kinds  *  (kindof)  :  design_and_con  struction 

partof  *  (parts) :  categories_of_parts_incl_in_parts_ctrl_pgm  connectors 
electrical_discharge_machining  allowed_matenals 
dielectric_requirements 

electrical_or_electronic_parts_vibraticm  forgings 
insulatk»n_resistance  conformal_coa tings  finishes 
corrosion_prevention 

clectrostatic_di  sch  arge_sen  sitive  metrication 
moun  tin  g_of_resistors_and_capaci  tors 
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selection_of_specifications_and_standanis  soldering 
prohibited_materials_and_parts  thermal_design 
electrical_grounding_and_bonding 
wire_shielding_grounding  wiring 
moisture_and_fungus_resistance 
printed_circuit_board_assemblies  optics 


{ 

metrication 

parts  *  (partof) :  material_processparts_parts 


{ 

microelectronic_devices 
parts  *  (partof) :  parts_reliability 


{ 

microwave_and_RF_emissions 
parts  *  (partof) :  safety 


{ 

module_perspecrives 

kindof  *  (kinds) :  manufacturing_or_producibility_perspective 

documentation  ..perspective  requirements_perspective 
software_perspective  test_verification_perspective 


{ 

moisture_and_fungus_resistance 
parts  *  (partof) :  material_processparts_parts 


{ 

mounting_of_resistors_and_capacitors 
parts  *  (partof)  :  material_processparts_parts 


{ 

off_aircraft_test_meastirement_and_dia  gnostic 
parts  *  (partof)  :  support_equipment 


{ 

optical 

kinds  *  (kindof) :  item.electrical 

} 

{ 

optics 
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parts  *  (partof) :  material_processparts_parts 


{ 

optimal_cost_or_time 
kindof  *  (kinds) :  least_cost  least_time 
kinds  *  (kindof) :  manufacturing_or_producibility_perspective 

} 

{ 

parts 

parts  *  (partof) :  interchangeability 

} 

{ 

parts_reliability 

kinds  *  (kindof) :  parts_seiection_criteria 
partof*  (parts) :  microelec  tronic_devices  passive_devices 
senriconductor_devices 

} 

{ 

parts_selection_criteria 
kindof  *  (kinds) :  parts_rcliability 
kinds  *  (kindof) :  material_processparts _parts 

} 

( 

passive_devices 

parts  *  (partof) :  parts_rcliability 


{ 

peculiar_SE 

parts  *  (partof)  :  support_equipment 

} 

{ 

personnel_and_training 
kinds  *  (kindof) :  requirements j>erspective 
partof*  (parts) :  personnel_j>ersonnel_and_training 
training_personnel_and_training 

) 

{ 

pcrsonnel_personnel_and_training 
parts  *  (partof) :  personnel_and_training 

} 

{ 

physical_selecticm_criteria 
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{ 

printed jcircuit_board_assemblies 
parts  *  (partof)  :  material_processparts_parts 


{ 

producibility_characteristics 

kinds  *  (kindof) :  manufacturing_or_produribility_perspective 
partof  *  (parts) :  availability _of_tnaterials  facilities  manpower 
production_rate_and_quantity  special_tooling 


{ 

production_capabilities 
parts  *  (partof) :  facilities 


{ 

production_or_inspection_rcquired 
kinds  *  (kindof) :  manufacturing_cr_producibility_perspective 
partof  *  (parts) :  low_rate_production  high_rate_production 


{ 

production_rate_and_quantity 

partof*  (parts) :  sizing_of_facility_for_subassembly_and_assembly 
parts  *  (partof) :  producibility_characteri sties 


{ 

programmmgjanguages 

lands  *  (kindof)  :  design_and_construction_software 

) 

{ 

prohibited_materials_and_parts 
parts  *  (partof) :  material_processparts_parts 

} 

{ 

qnality_and_cost_of_tools 
parts  *  (partof)  :  special_tooling 

} 

{ 

reliability 

kinds  *  (kindof) :  characteristics 

maintenance _)evel : 

parameter: 

reference : 

unit: 


Page  81 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report  Appendix  A 


value: 

} 

{ 

rcliable_concrete_design_infomaiion 
parts  *  (partof) :  clarity_of_technical_data_package 

} 

{ 

requirements jxrspective 
kindof  *  (kinds) :  item_definition  characteristics 

design_and_construction  documentation  logistics 
personnel_and_training 
kinds  *  (kindof) :  module_perspectives 

} 

{ 

reset 

kinds  *  (kindof) :  item_discretes 

} 

{ 

safety 

kinds  *  (kindof)  :  design_and_construction 
partof  *  (parts) :  electncal_safety  LRM_safety 

microwave_and_RF_emissions  safety _personnel 

} 

{ 

safety_personnel 
parts  *  (partof) :  safety 
partof  *  (parts) :  health_hazards 

} 

{ 

selection_criteria_for_specified_materials 
kinds  *  (kindof) :  design_characteristics 
kindof  *  (kinds) :  selection_criteria_mechanical 

selecdon_criteria_physical  selection_criteria_chemical 

} 

{ 

selecuon_crit©tia_physical 

kinds  *  (kindof) :  selection_criteria_for_specified_materials 

} 

{ 

relectionjcriteriajchemical 

kinds  *  (kindof) :  selection_cri  ten  a_for_specified_material  s 

} 

{ 
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selection_criteria_mechanical 

kinds  *  (kindof) :  selection_criteria_for_specified_material  s 

} 

{ 

selection_of_spccifications_and_standards 
parts  *  (partof)  :  material_processparts_parts 


{ 

semiconductor_de vices 
parts  *  (partof)  :  parts_reliability 

} 

{ 

simplicity_and_standard_in_comps_and_manuf_procs 
parts  *  (partof) :  least_cost 

} 

{ 

simplicity_of_design 

kindof  *  (kinds) :  fabrication  inspection  installation  checkout 
acceptance  test 

parts  *  (partof) :  design_characteristics 

} 

{ 

sizmg_of_facility_for_subassembly_and_assembly 
parts  *  (partof)  :  production_rate_and_quantity 


{ 

softwarejntegration 

kinds  *  (kindof)  :  design_and_construction_software 

} 

{ 

software_perspective 
kinds  *  (kindof) :  module_perspectives 

) 

{ 

software_perspectives 
parts  *  (partof)  :  design_objectives 


{ 

softwarc_sizing_and_timing_constraints 
kinds  *  (kindof) :  design_and_construction_software 

} 

{ 
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soldering 

parts  *  (partof)  :  material_processparts_parts 


{ 

spares 

partof  *  (parts) :  estimated_annual_operating_hours 
estimated_test_equipment_cost 
estimated_technical_manual_cost 
estimated_training_cost  tum_around_time 


{ 

spares_cost 

parts  *  (partof) :  equipment_life_cycle_cost 


{ 

special_tooling 

partof*  (parts) :  quality_and_cost_of_tools 
parts  *  (partof) :  producibility characteristics 


{ 

specifications 
filename: 
location : 
reference: 
spec_NO : 
tool : 

} 

{ 

specs 

kinds  *  (kindof) :  documentation 

} 

{ 

supply 

kinds  *  (kindof)  :  logistics 

} 

{ 

support_equipment 
kinds  *  (kindof) :  logistics 
partof  *  (parts) :  peculiar_SE  in_theater_depot_SE 
continental_US_depot_SE 
ofF_aircraft_test_measurement_and_diagnostic 

name : 
reference: 
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{ 

systcm_safety_or_hcalth_hazards 
parts  *  (partof) :  manpower_and_personnel_integration 

} 

{ 

technicaljmanuals 
kinds  *  (kindof) :  documentation 
manual_NO : 
reference: 
tide: 
tool: 
type: 

} 

{ 

rest 

kinds  *  Qrindof) :  simplicity_of_design 

} 

{ 

test_or_verification_perspective 
parts  *  (partof) :  design_objectives 

} 

{ 

test_verification_perspective 
kinds  *  (kindof) :  module_perspectives 

} 

{ 

testability 

kinds  *  (kindof) :  characteristics 
maintenance_level : 

} 

{ 

thermal_design 

parts  *  (partof) :  material_processparts_parts 

partof  *  (parts) :  junction_temperature  thermal_protection 

} 

{ 

thennal_protection 
parts  *  (partof) :  thermal_design 

} 

{ 

tolerance_requirements 
kinds  *  (kindof) :  design_characteri sties 
partof  ♦  (parts) :  identify_Min_quality_levels_required_to_roeet 
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} 

{ 

tolerances 

parts  *  (partof)  :  high_rate_production 


{ 

training  personnel  and  training 
parts  *  (partof) :  personnel_and_training 

} 

{ 

tum_around_time 
parts  *  (partof) :  spares 

} 

{ 

wire  shielding^  grounding 
parts  *  (partof) :  material_processparts_parts 

} 

{ 

wiring 

parts  *  (partof) :  material_processparts_parts 

} 

{ 

workmanship 

kinds  *  (kindof) :  design_and_construction 

} 
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Appendix  B.  Process  Model 

This  appendix  contains  data  on  the  electronics  module  process  model  used  in  the  DICE  Project 
Coordination  Board  on  die  Electronics  Pilot  Project  The  following  information  is  contained: 

1 .  MacProject  Activity  Network  Chart  For  Pilot  Project  Tasks  Page  88 

2.  Listings  for  Electronic  Module  Process  Model  Inputs  to  Project  Coordination  Board  Page  89 
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Listings  for  Electronic  Module  Process  Model  Inputs  to 
Project  Coordination  Board 

{ Analyze_For_Produribility 

next_tasks  *  (previous_tasks) :  Support_Material_Rqmts_Planning_MRP 

previous_tasks  *  (next_tasks) :  Perform_E)etailed_Electrical_Design 

description : 

destination :  "Manufacturing_Engineering" 
due_date : 

earliestJSnish :  "7/10/92" 
eariiest_start :  "6/25/92" 
focus : 

output :  "Producibility  Plan  Update" 

} 

{ Assess_New_Mfg_Processes 

next_tasks  *  (previous_tasks) :  Develop_Detailed_Process_Instructions 

previous_tasks  *  (next_tasks) :  Develop_Analyze_Detailed_Mfg_Processes 

description : 

destination :  "Manufacturing_Engineering" 
due_date : 

eariiest_finish :  "6/26/92" 
eariiest_start :  "6/15/92" 
focus : 

output :  "Design  Guideline  Update  To  PP" 

} 

{ Qoseout__CDR_Action_Items 

next_tasks  *  (previous_tasks) :  End_DICE_Phase_IV 

previous_tasks  *  (next_tasks) :  Conduct_Critical_Design_Review_CDR 

description : 

destination :  "System_Engineering" 
due_date : 

earliest_finish :  "8/12/92" 
earliest_start :  "8/6/92" 
focus : 

output :  "CDR  Completion  Certificate" 

} 

{  QoseoutJ?DR_ActionJtems 

next_tasks  *  (prcvious_tasks) :  Perform J3etatiedJ51ectrical_Design 

previous_tasks  *  (next_tasks) :  Update_ICD_B2_Specs 

description: 

destination :  "System_Engineering" 
duejdate : 

eariiest.finish :  "6/10/92" 
earliest_start :  "6/4/92" 
focus : 

output :  "PDR  Completion  Certificate" 

} 

{ Conduct_Critical_Design_Review_CDR 

next_tasks  *  (previous_tasks) :  Qoseout_CDR_Action_Items 

Release_Final _Drawing_Package 

previous_tasks  *  (next_tasks) :  Prcpare_Detailed_Test_Requirements 
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Finalize_Producibility_Plan 
Perfarm_Detailed_Maint_Analvsis 
Perform_Detailed_Thermal_Aiialysis 
description :  destination :  "System_Engineering" 
due_date : 

eariiest_finish :  "8/5/92" 
earliest_start :  "8/5/92" 
focus : 

output :  "CDR  Minutes/Action  Items" 

} 

{  Conduct_LCC_Analysis 

next_tasks  *  (prcvious_tasks) :  Perform_DetaiIed_Maint_ Analysis 

previous_tasks  *  (next_tasks) :  Conduc  t_LS  A_Analy  sis 

description : 

destination :  "Supportability Engineering" 
due_date : 

eariiest_finish :  ’7/17/92" 
eariiest_start :  "7/2/92" 
focus : 

output :  "LCC  Report" 

{  Conduct_LSA_Analysis 

next_tasks  *  (prcvious_tasks) :  Conduct_LCC_Analysis 

previous_tasks  *  (next_tasks) :  Conduct_Maint_Trade_Studies 

description : 

destination :  "Supportability_Engineering" 
due_date : 

eariiest_finish :  ’7/1/92" 
eariiest_start :  "6/18/92" 
focus: 

output :  "LSA  Report" 

{ Conduct_Maint_Tradc_Studies 

next_tasks  *  (previous_tasks) :  Conduct_LSA_Analysis 

previous_tasks  *  (next_tasks) :  Conduct_Prelim_Design_Review_PDR 

description : 

destination :  "Supportability_Engineering" 
duejdate : 

earliest_finish :  "6/17/92" 
eariiest.start :  "6/4/92" 
focus: 

output :  "Maintainability  Requirements  (B2  Update)" 

{ Conduct_Prelim_Design_Review_PDR 

next.tasks  *  (pievious_tasks) :  Update_ICD_B2_Specs 

Conduct_Maint_Trade_S  tudies 

Define_PCB_Layout_Guidelines 

Define_Detailed_Mechanical_Design 

previous_tasks  *  (next_tasks) :  Perform_Prelim_Maint_Ana]ysis 

Perform _Prelim_Mechanical_Design 
Perform_Prelim_BIT_Analysis 
Create J)esign_To_CostElan_Goals 
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Develop_Prelim_LRM_Parts_List 
Perform_Prelim_Failure_Analysis 
description :  destination :  "System_Engineering" 
due_date : 

earliest_finish :  "6/3/92" 
earliest_start :  "6/3/92" 
focus : 

output :  TDR  Minutes/Action  Items" 

} 

{ Conduct_Prelimmary_Producibility_Analysis 

next_tasks  *  (previous_tasks) :  Evaluate_Detailed_Mfg_Technology_Rqmts 

prcvious_tasks  *  (next_tasks) :  Create_Design_To_Cost_Plan_Goals 

description : 

destination :  "ManufacturingJEngineering" 
due_date : 

earliest_finish :  "6/5/92" 
earliest_start :  "5/22/92" 
focus : 

output :  "Pioducibility  Analysis  Report” 

} 

{  Create JDesignJTo_Cost_Plan_Goals 

next_tasks  *  (previous_tasks) :  Conduct_Preliminary_Producibility_Analysis 

Conduct_Prelim_Design_Review_PDR 
previous_tasks  *  (next_tasks) :  Define_Preliminary_Mfg_Rqmts 

Develop JLRM_Design_Concepts_Solutions 

description : 

destination :  "ManufacturingJEngineering" 
due_date : 

earliest_finish :  "5/26/92" 
earliest_start :  ”5/19/92" 
focus : 

output :  "DTC  Plan" 

} 

{ Define_Detailed_Mechamcal_Design 
next_tasks  *  (previous_tasks) : 
previous_tasks  *  (next_tasks) : 
description : 

destination :  "Mechanical JEngineering" 
due_date : 

earliest_finish :  "6/17/92" 
earliest.start :  " 614192 " 
focus : 

output :  "Drawings/Digital  Data" 

} 

{ Define _LRM_Interfaces 

next_tasks  *  (previous_tasks) : 
previous_tasks  *  (next_tasks) : 
description : 

destination :  "System_Engineering" 
duejdate: 


Perform_LRM_Grcuit_Paxtitioning 

Conduct_Prelim_Design_Review_PDR 


Develop_LRM_Design_Concepts_Solutions 

Refine_Interface_Rqmts 


earliest_finish :  "4/3/92" 
earliest_start :  "3/23/92" 
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focus : 

output :  "Preliminary  Intfc  Cntrl  Doc  (ICD)" 

} 

{ Define_Maint_Design_Criteria 

next_tasks  *  (previous_tasks) :  Perform_Prelim_Maint_Analysis 

previous_tasks  *  (next_tasks) :  Develop_LRM_Design_Concepts_Solutions 

Refine_T estability  Alloc  ations 

description : 

destination :  "Supportability_Engineering" 
due_date : 

eariiestjfinish :  "5/4/92" 
earliest_start :  "4/21/92" 
focus : 

output :  "Maintainability  Design  Criteria" 

{ Define_PCB_Layout_Guidelines 

next__tasks  *  (previous_tasks) :  Perform_Detailed_Electrical_Design 

Perfcnrn_LRM_Circuit_Partitioning 

previous_tasks  *  (next_tasks) :  Conduct_Prelim_Design_Review_PDR 

description : 

destination :  "Electrical_Engineering" 
due_date : 

earliest_finish :  "6/17/92" 
earliest_start :  "6/4/92" 
focus  : 

output :  "Preliminary  Level  I  Drawings" 

{ Define_Preliminary_Mfg_Rqmts 

next_tasks  *  (previous_tasks) :  Create_Design_To_Cost_Plan_Goals 

previous_tasks  *  (next_tasks) :  Evaluate_Procurement_Strategy 

Develop_Mfg_Strategy 
Evaluate_Production_Strategy 
description :  destination :  "Manufacturing_Engineering " 
due_date: 

earliest_finish :  "5/20/92" 
earliest_start :  "5/14/92" 
focus : 

output :  "Updated  Manufacturing  Plan” 

{ E>eterntine_Ctompatibility_With_Current_Capabilities 

next_tasks  *  (previous_tasks) :  Finali^_Produribility_Plan 

previous_tasks  *  (next_tasks) :  Develop_Detailed_Process_Instructions 

description: 

destination :  ”Manufacturing_Engineering” 
due.date  : 

earliest_finish :  ”7/28/92" 
eariiest_start :  ’7/15/92" 
focus : 

output :  "Design  Gttideline  Update  To  PP" 

{ Dev_Pnxi_Test_Eqpt_PTE_Rqmts 

next.tasks  *  (previousjtasks) :  Develop_Detailed_Process_Instructic«i  s 
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previous_tasks  *  (nextjtasks) :  Develop_Analyze_Detailed_Mfg_Processes 

description : 

destination :  "ManufacturingJEngineering" 
due_date : 

eariiest_finish :  'in  192" 
eaiiiest_start :  "6/22/92" 
focus : 

output :  'Test  Requirements  Report" 

{ Develop_Analyze_Detailed_Mfg_Processes 

next_tasks  *  (previous_tasks) :  Assess_New_Mfg_Processes 

Dev_.Prod_Test_Eqpt_PTE_Rqmts 

previous_tasks  *  (next.tasks) :  Evaluate_Detailed_Mfg_T echnology_Rqmts 

description : 

destination :  "Manufacturing_Engmeering" 
due.date : 

eariiest_finish :  "6/19/92" 
eariiestjstart :  "6/8/92" 
focus : 

output :  "Process  Flow  Update  To  PP" 

{ Develop_Detailed_Process_Instructions 

next_tasks  *  (previous_tasks) :  Determine_CompatibiHty_With_Current 

.Capabilities 

Support_Testability_Design_Analysis 
Support_Material_Rqmts_Planning_MRP 
previous.tasks  *  (next.tasks) :  Assess_New_Mfg_Processes 

Dev_Prod_Test_Eqpt_PTE_Rqmts 

description : 

destination :  "ManufacturingJEngineering" 
due.date : 

eariiest.fimsh :  ’7/14/92" 
earliest.start :  "6/29/92" 
focus: 

output :  "Process  Instructions  Update  To  PP" 

{ Devclop_LRM_Design_Concepts_Solutions 

next_tasks  *  (previous.tasks) :  Perfonn_Mechanical_Trade_Studies 

Develop_Reliability_Math_Model 
Develc^_PrelimJJRM_Electrical_Design 
Develop_LRM_Testability_Approach 
Define_Maint_Design_Criteria 
PerfoaTn_Prelim_Mechanical_Design 
Create_Design_To_Cost_Plan_Goals 
previouSjtasks  *  (next.tasks) :  Develop_Prclim_LRM_Fnctl_Desi  gn 

Define_LRM_Interfaces 

description: 

destination :  ,rElectrical_Engineering" 
due.date: 

earliestjfinish :  "4/27/92" 
eariiest.start:  "4/13/92" 
focus: 
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output :  "Sketches/Layouts" 

{ Develop_LRM_Testability_Approach 

next_tasks  *  (previous_tasks) :  Perform_Prelim_BIT_Analysis 

previous_tasks  *  (next_tasks) :  Establish_Test_Philosophy 

Develop_LRM_Design_Concepts_Solutions 

description : 

destination :  "Supportability_Engmeermg" 
due_date : 

earliest_finish :  "4/27/92” 
eariiest_start :  ”4/21/92" 
focus : 

output :  "Testability  Approach" 

{ Develop_Mf g_S  trategy 

next_tasks  *  (previous_tasks) :  Define_Preliminary_Mfg_Rqmts 

previous_tasks  *  (next_tasks) :  Generate_Initial_Producibility_Plan 

description : 

destination :  "Manufacturing_Engineering" 

^esffinish :  "5/13/92" 
eariiest_start :  "5/7/92” 
focus: 

output :  "Manufacturing  Plan" 

{ Develop_Prelim_IJlM_Electrical_Design 

next_tasks  *  (previous_tasks) :  Perform_Prelim_Brr_Analysis 

DeveIop_Prclim_LRM_Parts_List 

previous_tasks  *  (next_tasks) :  Devek^JLRM_Design_Concepts_SoIutions 

description : 

destination :  "Hectrical_Engineering" 
due_date : 

earliestjBnish :  "5/18/92" 
earliest_start :  "4/28/92" 
focus: 

output :  "Detailed  SPX-32  Block  Diagrams" 

{ Develop_Prclim_LRM_FnctI_Dcsign 

next_tasks  *  (prcvious_tasks) :  Develop_LRM_Design_Q)ncepts_SoIutions 

previous_tasks  *  (next_tasks) :  Flow_Down_Dcsign_Rqmts_To_Comp_Assy 

description : 

destination :  "System_Engineering" 
duejdate : 

eariiest_finish :  "4/27/92" 
eariiestjstart :  "4/6/92" 
focus : 

output :  "SPX-32  Functional  Block  Diagrams" 

{ Develop JPrelim_LRM_Parts_List 

next_tasks  *  (prcvious_tasks) :  Conduct_Prclim_Design_Review_PDR 

previous_tasks  *  (next_tasks) :  Develop_Prclim_LRM_ElectricaLDesign 

description : 
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destination :  "Electrical_Engineering" 
due_date : 

earliest_finish :  "5/18/92" 
earliest_start :  ”5/5/92" 
focus : 

output :  "Preliminary  Parts  List" 

} 

{ Devel(^)_Reliability_Math_Model 

next_tasks  *  (previous_tasks) :  Perfonn_Prelim_Failure_Analysis 

previous_tasks  *  (next_tasks) :  Develop_LRM_Design_Concepts_Solutions 

description : 

destination :  "Supportability_Engineering" 
duejdate: 

earliest_finish :  "5/11/92" 
earliest_start :  "4/28/92" 
focus : 

output :  "Reliability  Math  Models" 

} 

{ End_DICEJPhase_IV 

previous_tasks  *  (next_tasks) :  Qoseout_CDR_Action_Items 

Release_Final_Drawing_Package 

description : 
destination : 
duejdate: 
eariiest_finish : 
earliest_start : 
focus: 
output: 

} 

{ EstablishL.Test_Philosophy 

next_tasks  *  (previous_tasks) :  Devdop_IJRM_Testalnlity_Approach 

previous.tasks  *  (next_tasks) :  Evaluate_Test_Rqmts 

description : 

destination :  "Supportability_Engineering" 
duejdate : 

earliest_finish :  "4/10/92" 
eariiest_start :  "3/30/92" 
focus : 

output :  "Testability  Fhilosphy" 

} 

{ Evaluate_Dctailed_Mfg_Technology_Rqmts 

next_tasks  *  (prcvious_tasks) :  Devdop_Analyze_Detailed_Mfg_Processes 

prcvious_tasks  *  (next_tasks) : 

Conduct_Prcliminary_Producibility_Analysis 

description: 

destination :  "ManufacturingJEngjneering" 
due.date: 

earliest_finish :  "6/12/92" 
eariiest_start:  "6/1/92" 
focus: 

output :  "Producibility  Plan  Update" 
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{ Evaluate_Procurement_S  trategy 

next.tasks  *  (previous_tasks) :  Define_Prelimmary_Mfg_Rqmts 

previous_tasks  *  (next_tasks) :  Genentfe_Initial_Producibtiity_Plan 

description : 

destination :  "Manufacturing_Engineering" 
duejdate: 

earliest_finish :  "5/8/92" 
eaiiiest_start :  "5IAI92" 
focus : 

output :  "Make/Buy  Plan  Update  To  PP" 

} 

[  EvaluateJE¥oduction_Strategy 

next_tasks  *  (previous_tasks) :  Define_Preliminaiy_Mfg_Rqmts 

previous_tasks  *  (next.tasks) :  Generate.ini  tial_Produribility_Plan 

description : 

destination :  "Manufacturing_EngineeringM 
duejdate: 

earliest_finish :  "5/6/92" 
earliest_start :  "4/30/92" 
focus : 

output :  "Producibility  Plan  Update" 

} 

{ Evaluate_Test_Rqmts 

next_tasks  *  (previous_tasks) :  Identify_T_E_Options 

Establish.TestJPhilosophy 

previous.tasks  *  (next_tasks) :  Refine.T estability Allocations 

description : 

destination :  "Supportability_Engineering" 
duejdate: 

eariiest.finish :  "4/3/92” 
earliest_start :  "3/23/92" 
focus: 

output :  "Test  Equipment  Approach" 

{ Finalize_Producibility_Plan 

next_tasks  *  (pievious_tasks) :  Cbnduct_Critical_Design_Review_CDR 

previous_tasks  *  (next.tasks) :  Support_Testability_Design_Analysis 

Stq>port_Material_Rqmts_Planning_MRP 

Detemrine_Coiiq>atibffity_With_^^ 

.Capabilities 

description :  destination :  "Manufacturing_Engineering" 
due.date : 

earliest.fimsh :  "8/4/92" 
eariiest.start:  "7/29/92" 
focus : 

output :  "Updated  Producibility  Plan" 

} 

{ Flow_Down_Dcsign_Rqmts_To_Comp_Assy 

next.tasks  *  (previous.tasks) :  Develc^)_Prelim_LRM_Fnctl_Design 

previous.tasks  *  (next.tasks) :  Refine_Power_ Allocations 

Refine.W t_S  ize_ Allocations 
Refine_Thermal_Allocation 
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Refine_Reliability_Allocation 
Refine_Fnctl_LRM_Allocaticms 
Rcfine_Interface_Rqmts 
Refine_T estability Allocations 
description  :  destination :  ”System_Engineering" 
due_date : 

eariiest_finish :  "4/10/92" 
eariicst_start :  "3/30/92" 
focus : 

output :  "Specs/SCD's/Drawings" 

} 

{ Generate_Initial_Producibility_Plan 

next_tasks  *  (previous_tasks) :  Evaluate_Producdon_Strategy 

Evaluate_Procurement_Strategy 

Develop_Mfg_Strategy 

previous_tasks  *  (next_tasks) :  Update_Family_Tree 

description: 

destination :  "Manufacturing_Engineering" 
due_date : 

eariiest_fimsh :  "5/1/92" 
earliest_start :  "4/27/92" 
focus : 

output :  ’Initial  Proudcibility  Plan  (PP)" 

} 

{ Identify JOLOptions 

next_tasks  *  (prcvious_tasks) :  Perform_T_E_Trade_Studies 

previous_tasks  *  (next_tasks) :  Evaluate_Test_Rqmts 

description : 

destination :  "Supportability_Engineering" 
duejdate : 

eariiest_finish :  "4/20/92" 
eariiest.start :  "4/6/92" 
focus : 

output :  "T&E  Trade  Study  Report" 

} 

{ Perform_Detailed_Qrcuit_Analysis  _ 

next_tasks  *  (previous_tasks) :  PreparrJDetailedJTestJRequirements 

previous_tasks  *  (next_tasks) :  Perfonn_Detailed_Electrical_Design 

description : 

destination :  "EIectrical_Engineering” 
duejdate: 

eaiiiest_finish :  "7/17/92" 
eariiest_start :  "7/2/92" 
focus : 

output :  "Electrical  Analysis  Report" 

} 

{ Perform_Detailed_Electrical  JDesign 

next_tasks  *  (previous_tasks) :  PerfcHTii_E>etailed_Circuit_Analysis 

Update_Sys_Verification_Plan 

Analyze_For_Producibility 

previous_tasks  *  (next_tasks) :  Define^PCB_Layout_Guidelines 

Qoseout _PDR_Action_Items 
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description : 

destination :  "Electrical_Engineering" 
due_date : 

earliest_finish :  ’7/1/92" 
carliest_start :  "6/11/92" 
focus : 

output :  "Final  Level  I  Drawings" 

} 

{ Perform_Detailed_Maint_Analysis 
next_tasks  *  (previous_tasks) : 
previous_tasks  *  (next_tasks) : 
description : 
destination : 
duejdate: 
eariiest_finish : 
earliest_start : 
focus: 
output : 

} 

{ Perform_Detailed_Thermal_Analysis 
next_tasks  *  (pievious_tasks) : 
previous_tasks  *  (next_tasks) : 
description : 

destination :  "Mechanical_Engineering" 
due_date : 

eariiest_finish :  "7/17/92" 
eariiest_start :  ’7/2/92" 
focus: 

output :  "Thermal  Analysis  Report" 

{  Perform_LRM_Circuit_Partitioning 
next.tasks  *  (previous_tasks) : 
previous_tasks  *  (next_tasks) : 

description : 

destination :  "E3ectrical_Engineering " 
duejdate: 

eariiest_finish :  ’7/1/92" 
eariiest_start :  "6/18/92" 
focus: 

output :  "PCB  Layout  Guidelines" 

{ Perform_Mechanical_Trade_S  tudies 
ncxt_tasks  *  (previous.tasks) : 

prcvious_tasks  *  (next_tasks)  : 

description: 

destination :  "Mechanical_Engineering" 
duejdate: 

earliest_finish :  ”5/4/92" 
eariiest_start :  "4/21/92" 


Conduct_Critical_Design_Review_CDR 
Conduct JLCC_Analysis 


Condua_CriticalJDesign_Review_CDR 

Perform_LRM_Ciicuit_P&ititioning 


Perfonn__Detailed_Thermal_Analysis 

Define_Detailed_Mechanical_Design 

Define_PCB_Layout_Guidelines 


Perform_Thennal_Trade_Studies 
Perf(xm_Prelim_Mechanical_Design 
Develop_LRM_Design_Concepts_Solutions 
Prepare J>rawing_Tree 
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focus : 

output :  "Mechanical  Requirements  (B2  Update)" 

} 

{ Perform_Prelim_Bn'_Analysis 

next_tasks  *  (previous_tasks) :  Conduct_Prelim_Design_Review_PDR 

prcvious_tasks  *  (next_tasks) :  Perform_T_E_Trade_Studies 

Devel<^)_Prelim_LRM_Electrical_Design 
Develop_LRM_T estability_Approach 
description :  destination :  "Supportability_Engineering" 
due_date : 

earliest_finish :  " 5126/92 " 
earliest_start :  "5/12/92" 
focus : 

output :  "BIT  Effectiveness  Report" 

} 

{ Perform JPrelim_Failure_Analysis 

next__tasks  *  (previous_tasks) :  Conduct_Prelim_Design_Review_PDR 

previous_tasks  *  (next_tasks) :  Develop_Reliability_Math_Model 

Perform_Thermal_Trade_Studies 

description : 

destination :  "Supportability_Engineering" 
due_date : 

earliest_finish :  "6/2/92" 
earliest_start :  "5/19/92" 
focus: 

output :  "Failure  Rate  Prediction  Report" 

} 

{ Perform_Prelim_Maint_Analysis 

next__tasks  *  (previous_tasks) :  Conduct_Prelim_Design_Review_PDR 

previous_tasks  *  (next_tasks) :  Define_Maint_Design_Criteiia 

description : 

destination :  "SupportabilityJEngineering" 
due  Harp. : 

earliest_finish :  "5/18/92" 
eariiest_stalt:,, 5/5/92" 
focus: 

output :  "Baseline  Maintainability  Rqxjrt" 

} 

{ Perfonn_Prelim_Mechanical_Design 

next_tasks  *  (previous_tasks) :  Conduct_Prelim_Design_ReviewJPDR 

previous_tasks  *  (next_tasks) :  Perfonn_Mechanical_Trade_Studies 

Develop_LRM_Design_Concepts_Solutions 

description : 

destination :  "MechanicalJEngineering" 
due  Hatp. : 

earlicstjSnish :  "5/18/92" 
eariiest_stait :  "5/5/92" 
focus: 

output :  "Preliminary  Mechanical  Sketches" 

} 

{ Perform_T_E_Trade_Studies 

next_tasks  *  (previous_tasks) :  Perform_Prelim_Bn'_Analysis 
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prcvious.tasks  *  (next_tasks) :  Identify JT_E_Options 

description : 

destination :  "SupportabilityJEngineering" 
dne  date ; 

earliest  .finish :  "4/27/92” 
eariiest_start :  "4/13/92" 
focus: 

output :  "Critical  Test  Interfaces" 

} 

{ Perform_Thermal_Trade_S  tudies 

next.tasks  *  (prcvious_tasks) :  Perform_Prelim_Failure_Analysis 

previous_tasks  *  (next.tasks) :  Perform_Mechanical_Trade_S  tudies 

description: 

destination :  "Mechanical_Engineering" 
due_date : 

earliest_finish :  "5/18/92" 
eariiest_start :  "5/5/92" 
focus: 

output :  "Thermal  Requirements  (B2  Update)" 

} 

{ Prepare.Detailed.Test.Requirements 

next_tasks  *  (previous_tasks) :  Conduct_Critical_Design_Review_CDR 

previous_tasks  *  (next.tasks) :  Perform_Detailed_Circuit_Analysis 

Update_Sys_Verification_Plan 

description : 

destination :  "Electrical_Engmeermg" 
due.date: 

eariiest_finish :  ’7/31/92" 
eariiest_start :  "7/20/92" 
focus: 

output :  'Test  Specifications" 

{ Prepare_Drawing_Tree 

next.tasks  *  (previous_tasks) :  Perfonn_Mechanical_Trade_Studies 

previous_tasks  *  (next_tasks) :  Updatc_F  amily_Tree 

description : 

destination :  "Mechanical_Engineering" 
due.date: 

earliest .finish :  "4/10/92" 
eariiest_start :  "4/6/92" 
focus : 

output :  "Drawing  Tree" 

{ Refine  JFnctl_LRM_Allocations 

next.tasks  *  (prcvious.tasks) :  Flow_Down_Design_Rqmts_To_Conip_Assy 

prcvious.tasks  *  (next.tasks) :  Review_System_Rqmts 

description : 

destination :  "System ^Engineering" 
due.date: 

earliest Jinish :  "3/2Q/92" 
eariiest_start:  "3/9/92" 
focus : 
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output :  "Functonal  Requirements  (B2  Update)" 

{ Refine_Interface_Rqmts 

next_tasks  *  (previous_tasks) :  Update_Family_Tree 

Flow_Do wn_Design_Rqmts_T o_Comp_ A  ssy 
Define_LRM_Interfaces 
previous_tasks  *  (next_tasks) :  Review_System_Rqmts 

description : 

destination :  "System_Engineering" 
due_date : 

eariiest_finish :  "3/20/92" 
eariiest_start :  "3/9/92" 
focus : 

output :  "Interface  Requirements  (62  Update)" 

{ Refine JPower_Allocations 

next_tasks  *  (previous_tasks) :  Flow_Down_Design_Rqmts_To_Comp_Assy 

previous_tasks  *  (next_tasks) :  Review_System_Rqmts 

description : 

destination :  "Electrical_Engineering" 
due_date : 

eariiest_finish :  "3/20/92" 
earliest_start :  "3/9/92" 
focus : 

output :  "Power  Requirements  (B2  Update)" 

{  Refine_Reliability_Allocation 

next_tasks  *  (previous_tasks) :  Flow_Down_Design_Rqmts_To_Comp_Assy 

previous_tasks  *  (ncxt_tasks) :  Review_System_Rqmts 

description: 

destination :  "Suppoitobitity_Engineering" 
due_date : 

earliest_finish :  "3/20/92" 
eariiest_start :  "3/9/92" 
focus : 

output :  "Reliability  Requirements  (B2  Update)" 

{  Refine_Testability  Allocations 

next_tasks  *  (previousjtasks) :  Flow_Down_Design_Rqmts_To_Q)mp_Assy 

Evaluate_Test_Rqmts 

Define_Maint_Design_Criteria 

previous_tasks  *  (next_tasks) :  Review_System_Rqmts 

description : 

destination :  "Supportability_Engineering" 
due  dale : 

earliest Jfinish :  "3/27/92" 
eariiest_start :  "3/1^92" 
focus: 

output :  "Testability  Requirements  (B2  Update)" 

( Refine_Thermal_Allocation 

next_tasks  *  (previous_tasks) :  Flow_Down_Design_Rqmts_To_Comp_Assy 
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previous.tasks  *  (next_tasks) :  Review_S  y stem_Rqmts 

description : 

destination :  "Mechanical_Engineering" 
due_date : 

eariiest_finish :  ”3/27/92" 
earliest.start :  "3/16/92" 
focus : 

output :  "Cooling  Requirements  (B2  Update)" 

{ Refine__Wt_Size_Allocations 

next_tasks  *  (previous_tasks) :  Flow_Down_Design_Rqmts_To_Comp_Assy 

previous_tasks  *  (next_tasks) :  Revie w_S ystem_Rqmts 

description: 

destination :  "Mechanical_Engineering" 
due_date : 

earliest_finish :  "3/20/92" 
eariiest_start :  "3/9/92" 
focus : 

output :  "Weight  &  Size  Requirements  (B2  Update)" 

{ Release Jfinal_Drawing_Package 

next.tasks  *  (prcvious_tasks) :  End_DICE_Phase_IV 

previous_tasks  *  (next_tasks) :  Conduct_Critical_Design_Review_CDR 

description: 

destination :  "Mechanical_Engineering" 
duejdate: 

eariiest_fimsh :  "8/6/92" 
earliest_start :  "8/6/92" 
focus : 

output :  "Final  SPX-32  Drawing  Pkg" 

{ Review_System_Rqmts 

next_tasks  *  (pirvious_tasks) :  Refine_Fnctl_LRM .Allocations 

Rrfme_Thermal_Allocation 
Refine_Reliability_Allocarion 
Refine ^Power.Allocations 
Refine_Testability Allocations 
Refine_Wt_Size_Allocations 
Refine_Interface_Rqmts 

description :  destination :  "SystemJBngineering" 
due_date : 

earliest.finish :  "3/6/92” 
eariiest_staxt :  "3/1/92" 
focus: 

output :  "Preliminary  B2  Spec" 

{  Support_Material_Rqmts_Planning_MRP 

next_tasks  *  (previous_tasks) :  Rnalize_Producibility_Plan 

previous.tasks  *  (next_tasks) :  Develop J)etailed_Process_Instnictions 

Analyze_For_Producibility 

description : 

destination :  "ManufacturingJEngineering" 
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duc_dale : 

eariiest_fijiish :  "8/4/92” 
earliest_start :  "7/22/92" 
focus : 

output :  "Master  Production  Schedule  Report" 

} 

{  Support_Testability_Design_Analysis 

next_tasks  *  (previous_tasks) :  Finalize_ProducibilityJPlan 

previous_tasks  *  (next_tasks) :  Develop_Detailed_Process_Instructions 

description : 

destination :  "Manufacturing_Engineering" 
due_date : 

eariiest_finish :  ’7/21/92" 
earliest_start :  "7/8/92" 
focus : 

outp  .t :  "Producibility  Plan  Update" 

} 

{ Update_Fanrily_Tree 

next_tasks  *  (previous_tasks) :  Prepare_Drawing_Tree 

Generate_Initial_Producibility_Plan 
previous_tasks  *  (next_tasks) :  Refine_Interface_Rqmts 

description : 

destination :  "System_Engineering" 
due_date : 

earliest_finish :  "4/3/92" 
earliest_start :  "3/23/92" 
focus : 

output :  "Updated  Famly  Tree" 

} 

{ Update_ICD_B2_Specs 

next_tasks  *  (previous_tasks) :  Closeout_PDR_Action_Iteins 

prcvious_tasks  *  (next_tasks) :  Conduct_Prelim_Design_Review_PDR 

description: 

destination :  "System_Engineering" 
due_date : 

earliest_finish :  "6/17/92" 
eariiest_start :  "6/4/92" 
focus : 

output :  "Final  B2  Spec  &  xCD" 

} 

{ Update_Sys_Verification_Plan 

next_tasks  *  (previous_tasks) :  Prepare_Detailed_Test_Requircments 

previous_tasks  *  (next_tasks) :  Perform_Detailed_Electrical_Design 

description: 

destination :  "System_Engineering" 
duejdate : 

eaxiiest_finish :  "7/17/92" 
eariiest_start :  ’7/2/92" 
focus : 

output :  "Design  Compliance  Matrix" 

} 
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Appendix  C.  Metrics  Data 


This  appendix  contains  additional  information  on  the  metrics  taken  during  the  DICE  Electronics 
Pilot  Project  design  activity.  The  following  information  is  contained; 


1.  Metrics  Definitions . Page  106 

2.  Form  for  Collection  of  Applied  Time  Metric . Page  113 

3.  Form  for  Collection  of  Environment  Metrics . Page  1 13 

4.  "Bug  Report"  Form . Page  1 14 
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APPLIED  TIME  METRIC  DEFINITION 

•  Description:  This  is  the  time  actually  spent  performing  the  individual  design  tasks  for  the 
pilot  project  module.  This  time  is  equivalent  to  the  time  that  would  be  entered  on  the 
employee's  time  card  for  the  productive  hours  spent  on  that  task. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  drive  the  product  development  cost 
down,  as  the  applied  time  charged  to  tasks  cm  a  project  directly  affects  the  development  cost. 

•  Population:  This  metric  is  to  be  collected  for  each  design  task  on  the  SPX32  pilot  project 
design,  as  defined  by  the  task  structure  in  the  DICE  Project  Coordination  Board. 

•  Frequency  and  source  of  measurement:  The  measurement  is  to  be  captured  every  business 
day.  Each  designer  captures  his  time  spent  on  his  assigned  tasks  on  a  sheet  similar  to  the 
time  card  system  used  at  Westinghouse.  This  time  sheet  also  captures  additional  data  used 
for  other  metrics,  and  includes  the  amount  of  time  logged  on  to  each  DICE  tool  and  the  actual 
start  and  finish  dates  for  each  task. 

•  Graphic  Presentation:  The  graphic  presentation  to  be  used  will  consist  of  a  spreadsheet  table 
showing  applied  time  for  each  task.  The  initial  presentation  for  the  pilot  project  will  consist 
of  a  table  containing  each  task,  the  baseline  time  for  each  task,  the  pilot  project  time  for  each 
task,  and  a  "corrected"  time  for  the  SPX  times,  which  takes  into  account  the  correction  for 
the  immaturity  of  the  tools  being  used,  as  the  characteristics  of  the  current  versions  of  the 
tools  include  reliability,  user  interface,  and  functionality  shortcomings  which  negatively 
affect  the  result  This  correction  factor  will  project  the  impact  on  the  applied  time  assuming 
the  tool  has  matured;  ie.,  that  the  recommended  improvements  being  fed  back  to  CERC  have 
been  successfully  implemented. 

•  Customers:  The  customers  of  the  metrics  are  the  individual  functional  groups  (electrical, 
mechanical,  manufacturing,  etc.)  responsible  for  performing  these  tasks  for  programs.  The 
functional  groups  use  the  metrics  to  provide  a  baseline  for  quoting  design  tasks  and  for 
monitoring  the  cost  performance  during  the  execution  of  the  tasks.  Program  offices  are  also 
customers  of  the  metrics  to  measure  cost  performance  against  the  program  plan. 

•  Accountable  process  owner:  The  owners  of  the  process  are  the  functional  groups  described 
above. 

•  Desired  outcome:  The  desired  outcome  is  a  trend  showing  a  decrease  in  the  hours  required  to 
perform  a  specific  task  over  a  number  of  programs,  as  it  indicates  that  the  time  (and  therefore 
the  labor  cost)  to  perform  the  task  decreased  as  DICE  tools  were  used. 
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CYCLE  TIME  METRIC 

•  Description:  The  cycle  time  is  the  elapsed  time  in  calendar  business  days  to  perform  a  task  on  the 
pilot  project  design  effort  This  time  starts  with  the  acknowledgement  of  a  task  on  the  PCB,  and 
ends  with  the  PCB  assertion  that  the  task  is  complete. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  drive  the  product  development  time 
down. 

•  Population:  The  population  of  tasks  consists  of  all  the  tasks  loaded  into  the  PCB  for  the  pilot 
project  design. 

•  Frequency  and  Source  of  Measurement:  The  cycle  time  measurement  will  be  made  once  for  each 
task.  No  capability  exists  in  the  PCB  for  capturing  a  log  of  acknowledged  and  completed  task 
dates,  so  manual  collection  of  these  times  is  to  be  performed  as  an  interim  approach  using  the  same 
form  as  the  applied  time  collection.  Each  member  of  the  design  team  is  responsible  for  entering  the 
actual  start  and  finish  dates  for  their  respective  tasks. 

•  Graphic  Presentation:  The  presentation  method  is  the  same  as  for  the  applied  time  metric.  The 
same  correction  factors  apply. 

•  Customers:  The  customers  are  the  same  as  the  applied  time  metric. 

•  Accountable  Process  Owner  The  process  owners  are  the  same  as  the  applied  time  metric. 

•  Desired  Outcome:  The  desired  outcome  is  a  trend  indicating  that  development  elapsed  time  is 
decreasing,  as  a  result  of  both  decreased  applied  time  for  each  task  and  increased  concurrency  in 
performing  the  tasks. 
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EVALUATION  OF  DESIGN  ATTRIBUTES  VS  REQUIREMENTS  METRIC 

•  Description:  This  metric  is  defined  as  the  percent  of  the  design  requirements  which  are  being  met 
by  the  current  state  of  the  design,  taken  at  a  particular  point  in  time. 

•Appropriate  action  to  be  driven:  This  metric  is  meant  to  improve  the  quality  of  the  design  by 
ensuring  that  all  design  requirements  have  been  met,  preferably  in  a  shorter  amount  of  time. 

•  Population:  The  requirements  to  be  used  in  the  metric  are  the  total  set  of  requirements  in  the 
Requirements  Specification  or  B2-Spec  for  die  pilot  project  design. 

•  Frequency  and  Source  of  Measurement*  The  Design  Assessment  Tool  (DAT)  feature  of  the 
Project  Coordination  Board  (PCB)  will  be  used  to  take  the  measurement  The  measurement 
frequency  is  desired  to  be  every  week  during  the  design  phase. 

•  Graphic  Presentation:  The  presentation  for  the  metric  will  be  a  graph  generated  by  the  DAT 
showing  the  requirement  values  and  the  actual  design  values  for  the  design. 

•  Customers:  The  customers  for  this  metric  are  die  program  design  lead  and  the  program  manager. 

•  Accountable  Process  Owner:  The  owners  for  the  process  for  assessing  this  metric  are  the 
program  design  lead  and  the  program  manager. 

•  Desired  Outcome:  The  desired  outcome  is  a  trend  showing  that  more  design  requirements  are 
being  met  earlier  in  the  design  phase  due  to  the  improved  design  capabilty  using  the  DICE  tools. 
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CHANGE  REQUESTS  METRIC 

•  Description:  This  metric  is  the  number  of  design  changes  that  are  requested  after  the  design  is 
released  to  the  fabrication  cycle. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  measure  the  quality  of  the  design. 

•  Population:  The  population  consists  of  all  design  changes  requested  for  the  pilot  project  module. 

•  Frequency  and  Source  of  Measurement:  The  measurement  will  be  made  during  a  future 
fabrication  phase  for  the  pilot  project  module,  on  a  cumulative  basis. 

•  Graphic  Presentation:  The  graphic  presentation  will  consist  of  a  histogram  showing  number  of 
change  requests  over  time. 

•  Customers:  The  customers  of  this  metric  are  the  project  office  and  the  functional  groups 
responsible  for  the  design  activity. 

•  Accountable  Process  Owner:  The  accountable  process  owners  for  improving  the  process  are  the 
functional  groups  performing  the  design. 

•  Desired  Outcome:  The  desired  outcome  is  a  trend  showing  a  decrease  in  change  requests  in  a 
quantity  of  programs  over  time.  Appropriate  complexity  factors  will  need  to  be  applied  to  compare 
programs  of  different  size  and  complexity. 


109 


Westinghouse  Electronic  Systems  Group 


DICE  Phase  4  Final  Report  Appendix  C 


SYSTEM  CRASHES  METRIC 

•  Description:  This  metric  is  the  number  of  times  the  system  crashes,  which  includes  all  incidents 
where  a  program  has  to  be  restarted,  data  has  to  be  reinitialized,  or  die  system  requires  rebooting. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  improve  the  reliability  of  the  DICE 
environment. 

•  Population:  This  metric  includes  all  crashes  in  the  DICE  environment  during  the  actual  pilot 
project  design  phase. 

•  Frequency  and  Source  of  Measurement:  This  measurement  will  be  taken  as  each  incident  occurs, 
using  the  Crash/Downtime/Rework  log  book  in  the  DICE  lab.  Each  incident  will  be  recorded 
immediately  after  die  incident  by  the  user  who  experienced  die  incident  The  data  will  be  compiled 
weekly. 

•  Graphic  Presentation:  The  graphic  presentation  will  consist  of  a  column  chart  plotting  number  of 
crashes  occurring  during  each  week. 

•  Customers:  The  customers  of  this  metric  are  the  DICE  system  administrator  and  the  CERC. 

•  Accountable  Process  Owner.  The  accountable  process  owner  is  the  DICE  system  administrator. 

•  Desired  Outcome:  The  desired  outcome  is  a  downward  trend  in  number  of  crashes,  indicating 
increased  reliability  of  the  system  and  its  software. 
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REWORK  TIME  METRIC 

•  Description:  This  metric  is  the  amount  of  time  required  to  redo  work  done  on  a  pilot  project 
design  task  due  to  a  system  crash  or  other  software  malfunction. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  improve  the  efficiency  of  the  DICE 
environment  by  reducing  lost  effort  due  to  DICE  environment  malfunctions. 

•  Population:  This  metric  will  be  taken  for  work  done  on  all  tasks  in  the  pilot  project  design  effort. 

•  Frequency  and  Source  of  Measurement:  This  measurement  will  be  captured  immediately  after  the 
rework  is  performed.  Each  designer  performing  rework  is  responsible  for  recording  the  rework  in 
the  Crash/Rework/Downtime  log  book  in  the  DICE  lab.  The  data  will  be  compiled  weekly. 

•  Graphic  Presentation:  The  graphic  presentation  will  consist  of  a  column  chart  plotting  hours  of 
rework  required  during  each  week. 

•  Customers:  The  customers  of  this  metric  are  tire  DICE  system  administrator  and  the  CERC. 

•  Accountable  Process  Owner  The  accountable  process  owner  is  the  DICE  system  administrator. 

•  Desired  Outcome:  The  desired  outcome  is  a  downward  trend  in  rework  time,  indicating  less 
productive  time  lost  due  to  system  malfunctions. 
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DOWNTIME  METRIC 

•  Description:  Downtime  is  the  amount  of  time  the  system  is  not  available  for  productive  use  by  the 
pilot  project  design  team  during  the  pilot  project  phase.  The  downtime  includes  the  time  the  system 
is  unavailable  due  to  a  crash  or  a  system  maintenance  activity.  The  downtime  is  defined  as  the 
time  between  the  system  being  unavailable  (such  as  the  crash  time  or  the  maintenance  start  time) 
and  the  time  the  system  is  restored  to  availability.  Downtime  due  to  crashes  which  are  user 
recoverable  (such  as  by  restarting  an  application  program  after  a  crash)  and  which  do  not  require 
system  administrator  support  are  not  included  in  this  metric,  but  are  included  in  the  crash  and 
rework  metrics. 

•  Appropriate  action  to  be  driven:  This  metric  is  meant  to  improve  the  reliability  and  availability  of 
the  DICE  environment 

•  Population:  The  population  for  the  metric  is  the  downtime  incurred  during  performance  of  the 
pilot  project  design  tasks. 

•  Frequency  and  Source  of  Measurement:  The  measurement  will  be  made  immediately  after  the 
system  is  made  available.  The  system  administrator  will  log  the  time  of  correction  of  the  problem 
and  the  computed  downtime  using  the  Crash/Downtime/Rework  log  book.  The  data  will  be 
compiled  weekly. 

•  Graphic  Presentation:  The  graphic  presentation  will  consist  of  a  column  graph  plotting  hours  of 
downtime  occuring  each  week. 

•  Customers:  The  customer  of  this  metric  is  the  DICE  system  administrator  and  CERC. 

•  Accountable  Process  Owner:  The  process  owner  is  the  DICE  system  administrator. 

•  Desired  Outcome:  The  desired  outcome  is  a  trend  showing  downtime  decreasing  as  a  function  of 
time. 
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DICE  *  APPLIED  TIME~  METRIC  DAILY  HME  S»£ET 

(Please  HII  out  daily  when  you  nil  your  timecard) 


NAME:  U.OUDS1 

WEEKENDING: 

PAY  PERIOD: 

QALY1ME  RECORDING  FORMAT: 

TOTAL  APPLIED  IWS/EDN  LOGGED-ON  IW5/PC8  LOGGED-ON  HRS /MONET  LOGGED-ON  HRS  1 

TASK  DESCRIPTION 

TASK 
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T 

W 

T 

F 
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/ 
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/ 

/ 

/ 

/ 
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/ 
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/ 

/ 
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Form  for  Collection  of  Applied  Time  Metrics 


DICE  CRASHMAMTENANCE/DOWNTME  LOG 


FOR  WEEK  OF: 


OKIE 


WE 


TOOL 


NODE 


LOGGED 


NOl 


(MUOO) 


(HH/MM) 


OSCMTON 


1001  _ 

1002 

1003 

1004 

1005 

1008 

1007 

1008 

1009 

1010 

ion 

ToTij 

1013 

1014 

1015 
10161 


ENTER  TC 
P0A  CAUSE 


SVS1BI 


SVSTBI 


|F  SYSTEMS  SUPPORT 
WASI 


(HWIMU) 


TOTAL 

lOOWNTSlE| 

(WS) 


TME 

(HRS) 


Form  for  Collection  of  Environment  Metrics 
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DICE  TOOL  BUG  REPORT 


Software 

Module(s) 

Version 

Location  (of  Software) 

DICE  Lab,  Westinghouse  Electric  Corporation,  Baltimore,  MD 

Platform  (Environment) 

Sun  Sparcstation  1  (SUNOS  4.1.1) 

Problem  No. 

Date 

Originator's  Name 

Phone 

(410)  765-9252 

Describe  Problem  (Be  as  specific  as  possible,  including  what  you  where  doing  when  the  problem  occurred) 


■type  of  Problem 

Error  (Required  for  proper  u*e)  Adaptation  (Should  be  «n  easier  way  to  do  this)  Enhancement  (New  requirement) 

Severity 

Tool  not  functional  Some  features  broken  Inconvenience  (work  around  exists) _ Inefficiau.  unclear,  etc. 

Additional  Comments  /  Information 


Received  by 


Dale 


Signature 


"Bug  Report"  Farm 
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